Re: Problem enabling pltcl
Lamar Owen <lamar.owen@wgcr.org> wrote:
: Patrick Logan wrote:
:> ERROR: Unrecognized language specified in a CREATE FUNCTION:
:> 'pltcl'. Recognized languages are sql, C, internal and the
:> created procedural languages.
:>
:> The docs say that pltcl is enabled if it is built with the TCL
:> option. What am I missing?
: CREATE LANGUAGE (command line utility 'createlang'). See the regression
: test shell script (src/test/regress/regress.sh) for an example using
: plpgsql. The PL's are not created and installed by default, apparently.
Thanks. I also had to create the handler function as per the
documentation for creating new procedural language interfaces.
Boy, the documentation sure read to me like all that was supposed to
be done automatically by the Makefile when configured for pltcl.
Not a big deal, but it wasn't clear to me this had to be done for each
database created. Is this a bug in the documentation?
--
Patrick Logan patrickdlogan@home.com
From bouncefilter Wed Sep 8 17:13:33 1999
Received: from academic.mssm.edu (academic.mssm.edu [146.203.1.9])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA08756
for <pgsql-hackers@postgresql.org>; Wed, 8 Sep 1999 17:13:06 -0400 (EDT)
(envelope-from ramirez@doc.mssm.edu)
Received: from doc.mssm.edu (adwr44.mssm.edu [146.203.33.44])
by academic.mssm.edu (8.9.1/8.9.1) with ESMTP id RAA24918
for <pgsql-hackers@postgresql.org>; Wed, 8 Sep 1999 17:07:18 -0400 (EDT)
Message-ID: <37D6CFA2.94AA5B38@doc.mssm.edu>
Date: Wed, 08 Sep 1999 17:05:38 -0400
From: Edwin Ramirez <ramirez@doc.mssm.edu>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Postgres Performance
References: <13293.936374961@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
If I do a large search the first time is about three times slower than
any subsequent overlapping (same data) searches. I would like to always
get the higher performance.
How are the buffers that I specify to the postmaster used?
Will increasing this number improve things?
The issue that I am encountering is that no matter how much memory I
have on a computer, the performance is not improving. I am willing to
fund a project to implement a postgres specific, user configurable
cache.
Any ideas?
-Edwin S. Ramirez-
Tom Lane wrote:
Edwin Ramirez <ramirez@doc.mssm.edu> writes:
I have a couple of large(?) tables which I would like to keep them in
memory (cached) so that searches are performed as fast as possible.
Is it possible to 'pin' the tables and it's indexes in memory?If the tables are being touched often, then they will stay in buffer
cache of their own accord. I doubt that pinning them would improve
performance --- if they do get swapped out it'd be because some other
table(s) need to be accessed now, and if you did have these tables
pinned you'd be taking a large hit in access performance for those other
tables because of inadequate buffer space. LRU buffering policy really
works pretty well, so I don't think you need to worry about it.currently I run the postmaster with the following setting:
postmaster -i -B 2048 -o '-S 2048'
Are there any other options/values which would yield better performance?If you have a reliable OS and power source, consider -o -F (no fsync).
This usually makes for a very substantial performance improvement, and
it can only hurt if your machine goes down without having performed
all the writes the kernel was told to do.regards, tom lane
************
From bouncefilter Wed Sep 8 17:35:33 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 RAA11500
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 17:34:52 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA01224;
Wed, 8 Sep 1999 17:33:32 -0400 (EDT)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PG_UPGRADE status?
In-reply-to: Your message of Wed, 08 Sep 1999 15:35:22 -0400
<37D6BA7A.BD73456D@wgcr.org>
Date: Wed, 08 Sep 1999 17:33:32 -0400
Message-ID: <1222.936826412@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Lamar Owen <lamar.owen@wgcr.org> writes:
[ messiness required to upgrade versions by piping data from a
pg_dumpall to a psql talking to the new version ]
It'd be considerably less messy, and safer, if you were willing to
stick the pg_dump output into a file rather than piping it on the fly.
Then (a) you wouldn't need to run both versions concurrently, and
(b) you'd have a dump backup if something went wrong during the install.
If you compressed the dump file, which is easy enough, it'd probably
also take less disk space than doing it the other way. A compressed
dump should usually be a good deal smaller than the database equivalent;
if you do an on-the-fly transfer then the peak usage is two full
on-disk copies of the database...
You can see how pg_upgrade would be useful in such a scenario, no?
pg_upgrade is hardly a magic panacea --- if the on-disk formats are
at all different, then you really have little choice short of a dump
under the old version and reload under the new. At most pg_upgrade
might help automate that process a little more.
We may have lost the option of pg_upgrade-like upgrades anyway.
I'm still waiting to hear Vadim's opinion about whether pg_upgrade
can be made safe under MVCC.
regards, tom lane
From bouncefilter Wed Sep 8 17:38:33 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA12084
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 17:37:57 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id WAA00576;
Wed, 8 Sep 1999 22:41:04 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909082141.WAA00576@argh.demon.co.uk>
Subject: Re: [HACKERS] Postgres Performance
To: ramirez@doc.mssm.edu (Edwin Ramirez)
Date: Wed, 8 Sep 1999 22:41:04 +0100 (BST)
Cc: pgsql-hackers@postgreSQL.org (PostgreSQL-development)
In-Reply-To: <37D6CFA2.94AA5B38@doc.mssm.edu> from "Edwin Ramirez" at Sep 08,
1999 05:05:38 PM
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
If I do a large search the first time is about three times slower than
any subsequent overlapping (same data) searches. I would like to always
get the higher performance.How are the buffers that I specify to the postmaster used?
Will increasing this number improve things?The issue that I am encountering is that no matter how much memory I
have on a computer, the performance is not improving. I am willing to
fund a project to implement a postgres specific, user configurable
cache.Any ideas?
-Edwin S. Ramirez-
I think that the fact you are seeing an improvement already shows a good level
of caching.
What happens the first time is that it must read the data off the disc. After
that the data comes from memory IF it is cached. Disc read will always be
slower with current disc technology.
I would imagine (Im not an expert, but through observation) that if you
drasticly increase the number of shared memory buffers, then when you
startup your front-end simply do a select * from the tables, it may even keep
them all in memory from the start.
M Simms
From bouncefilter Wed Sep 8 17:43:34 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 RAA12975;
Wed, 8 Sep 1999 17:43:32 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA01242;
Wed, 8 Sep 1999 17:42:46 -0400 (EDT)
To: patrickdlogan@home.com
cc: pgsql-hackers@postgresql.org, pgsql-docs@postgresql.org
Subject: Re: [HACKERS] Re: Problem enabling pltcl
In-reply-to: Your message of Wed, 08 Sep 1999 20:32:09 GMT
<dJzB3.16297$Hu6.6589@news.rdc1.wa.home.com>
Date: Wed, 08 Sep 1999 17:42:45 -0400
Message-ID: <1240.936826965@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Patrick Logan <patrick@c837917-a.potlnd1.or.home.com> writes:
: CREATE LANGUAGE (command line utility 'createlang'). See the regression
: test shell script (src/test/regress/regress.sh) for an example using
: plpgsql. The PL's are not created and installed by default, apparently.
Boy, the documentation sure read to me like all that was supposed to
be done automatically by the Makefile when configured for pltcl.
Not a big deal, but it wasn't clear to me this had to be done for each
database created. Is this a bug in the documentation?
Probably. You should be able to just use the createlang utility without
worrying about the details, but I don't think that the install process
ought to do it for you. The procedural languages are supposed to be
installable on a per-database basis, in case you want them in some
databases and not others.
You *can* do a one-time install of a language for a whole installation,
by installing the language into template1 before you create any working
databases --- this works because "create database" clones whatever is in
template1. (I believe that holds for anything you stick in template1,
BTW, not just languages.)
But if the install process were to install pltcl into template1 just
because you had chosen to build pltcl, then you'd lose the option of
only having it in some of your databases.
Bottom line: I think the install process is correct as is, but the docs
need to be updated to mention these considerations.
regards, tom lane
From bouncefilter Wed Sep 8 18:02:33 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA16622
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 18:02:29 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id RAA25843;
Wed, 8 Sep 1999 17:43:03 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909082143.RAA25843@candle.pha.pa.us>
Subject: Re: [HACKERS] PG_UPGRADE status?
In-Reply-To: <37D6BA7A.BD73456D@wgcr.org> from Lamar Owen at "Sep 8,
1999 03:35:22 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Wed, 8 Sep 1999 17:43:03 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Lamar Owen wrote:
If I were a better C coder, and had more experience with the various
versions' on-disk formats, I'd be happy to try to tackle it myself.
But, I'm not that great of a C coder, nor do I know the data structures
well enough. Oh well.You would have to convert tons of rows of data in raw format. Seems
like dump/reload would be easier.For normal situations, it is. However, in an RPM upgrade that occurs as
part of an OS upgrade (say, from RedHat 6.0 to RedHat 6.1), NO daemons
can be run during a package upgrade. That doesn't seem too bad until you
realize just what an RPM upgrade does....
Wow, doing a database upgrade inside an automated RPM. That's quite a
task. From your description, running pg_dumpall and psql to load the
data is a real chore in an automated system.
Considering the changes in aligment of row elements, and index table
changes, it would be quite difficult to write a program to convert that
data from one format to another. Not impossible, but quite hard.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Sep 8 18:10:34 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA17836
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 18:10:22 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id SAA10340;
Wed, 8 Sep 1999 18:07:18 -0400
Message-ID: <37D6DE0D.DE0B1BF8@wgcr.org>
Date: Wed, 08 Sep 1999 18:07:09 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PG_UPGRADE status?
References: <1222.936826412@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Lamar Owen <lamar.owen@wgcr.org> writes:
[ messiness required to upgrade versions by piping data from a
pg_dumpall to a psql talking to the new version ]It'd be considerably less messy, and safer, if you were willing to
stick the pg_dump output into a file rather than piping it on the fly.
Then (a) you wouldn't need to run both versions concurrently, and
(b) you'd have a dump backup if something went wrong during the install.
Pipe or file, both versions have to be installed at the same time, so,
either way, it's messy. But, you are right that putting it in a file
(which is the way I manually update now) is a little less hairy. But
not by much.
You can see how pg_upgrade would be useful in such a scenario, no?
We may have lost the option of pg_upgrade-like upgrades anyway.
I'm still waiting to hear Vadim's opinion about whether pg_upgrade
can be made safe under MVCC.
I'm curious as to how difficult it would be to rewrite pg_upgrade to be
substantially more intelligent in its work. Thanks to CVS, we can
access the on-disk formats for any version since creation -- ergo, why
can't a program be written that can understand all of those formats and
convert to the latest and greatest without a backend running? All of
the code to deal with any version is out there in CVS already. It's
just a matter of writing conversion routines that:
0.) Backup PGDATA.
1.) Determine the source PGDATA version.
2.) Load a storage manager (for reading) corresponding to that version.
3.) Load a storage manager (for writing) corresponding to latest
version.
4.) Transfer tuples sequentially from old to new.
5.) Walk the PGDATA hierarchy for each and every database directory,
then update PG_VERSION and other needed files.
What am I missing (in concept -- I know there are alot of details that
I'm skimming over)? The hard part is getting storage readers for every
major version -- and there's not been THAT many on-disk format changes,
has there?
Now, I realize that this upgrading would HAVE to be done with no
backends running and no transactions outstanding -- IOW, you only want
the latest version of a tuple anyway. Was this the issue with
pg_upgrade and MVCC, or am I misunderstanding it?
Just the ramblings of a packager trying to make upgrades a little less
painful for the masses.
Lamar Owen
WGCR Internet Radio
From bouncefilter Wed Sep 8 18:18:33 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA18931
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 18:18:21 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id SAA10358;
Wed, 8 Sep 1999 18:18:01 -0400
Message-ID: <37D6E08F.34A1559E@wgcr.org>
Date: Wed, 08 Sep 1999 18:17:52 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PG_UPGRADE status?
References: <199909082143.RAA25843@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Lamar Owen wrote:
For normal situations, it is. However, in an RPM upgrade that occurs as
part of an OS upgrade (say, from RedHat 6.0 to RedHat 6.1), NO daemons
can be run during a package upgrade. That doesn't seem too bad until you
realize just what an RPM upgrade does....Wow, doing a database upgrade inside an automated RPM. That's quite a
task. From your description, running pg_dumpall and psql to load the
data is a real chore in an automated system.
Oliver Elphik has done this for the Debian packages -- but debs don't
have some of the draconian restrictions RPM's do. In particular, and
RPM that is packaged in the Official Boxed Set CANNOT under any
circumstances ask for input from the user, nor can it output anything to
the user. RPM's that do so get kicked out of the boxed set. And,
frankly, PostgreSQL's position in the boxed set is a Big Win.
Considering the changes in aligment of row elements, and index table
changes, it would be quite difficult to write a program to convert that
data from one format to another. Not impossible, but quite hard.
Reference my message to Tom Lane. Yes, such a program would be hard --
but most of it is already written and available in CVS -- thank God for
CVS! -- all that's needed is to extract the storage managers for each
major version, extract the reading code, etc, to get the on-disk
representation to an intermediate in memory form, then write it out with
the latest and greatest storage manager (into a different file, of
course, until the upgrade is finished). Unless I badly misunderstand
the way PostgreSQL does things, that should work -- but I may not have
expressed it the same way I see it in my mind.
I'm talking about a stripped down backend, in essence, whose only
purpose in life is to copy in and copy out -- but who has the unique
ability to read with one storage manager and write with another. You
simply choose which storge manager is used for reading by the version of
the PGDATA tree.
Piecing together the right CVS code snippets will be a challenge.
Lamar Owen
WGCR Internet Radio
From bouncefilter Wed Sep 8 18:24:34 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 SAA20017
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 18:24:26 -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 SAA01379;
Wed, 8 Sep 1999 18:22:49 -0400 (EDT)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PG_UPGRADE status?
In-reply-to: Your message of Wed, 08 Sep 1999 18:07:09 -0400
<37D6DE0D.DE0B1BF8@wgcr.org>
Date: Wed, 08 Sep 1999 18:22:49 -0400
Message-ID: <1377.936829369@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Lamar Owen <lamar.owen@wgcr.org> writes:
Tom Lane wrote:
It'd be considerably less messy, and safer, if you were willing to
stick the pg_dump output into a file rather than piping it on the fly.
Then (a) you wouldn't need to run both versions concurrently, and
(b) you'd have a dump backup if something went wrong during the install.
Pipe or file, both versions have to be installed at the same time, so,
either way, it's messy.
Er, no, that's the whole point. The easy way to attack this is
(1) While running old installation, pg_dumpall into a file.
(2) Shut down old postmaster, blow away old database files.
(3) Install new version, initdb, start new postmaster.
(4) Restore from pg_dump output file.
I'm curious as to how difficult it would be to rewrite pg_upgrade to be
substantially more intelligent in its work. Thanks to CVS, we can
access the on-disk formats for any version since creation -- ergo, why
can't a program be written that can understand all of those formats and
convert to the latest and greatest without a backend running? All of
the code to deal with any version is out there in CVS already.
Go for it ;-).
Now, I realize that this upgrading would HAVE to be done with no
backends running and no transactions outstanding -- IOW, you only want
the latest version of a tuple anyway. Was this the issue with
pg_upgrade and MVCC, or am I misunderstanding it?
The issue with MVCC is that the state of a tuple isn't solely determined
by what is in the disk file for its table; you have to also consult
pg_log to see whether recent transactions have been committed or not.
pg_upgrade doesn't import the old pg_log into the new database (and
can't very easily, since the new database will have its own), so there's
a problem with recent tuples possibly getting lost.
OTOH, it seems to me that this was true in older releases as well
(pg_log has always been critical data), so I guess I'm not clear on
why pg_upgrade worked at all, ever...
regards, tom lane
From bouncefilter Wed Sep 8 18:45:34 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA23289
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 18:45:03 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id SAA27594;
Wed, 8 Sep 1999 18:34:40 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909082234.SAA27594@candle.pha.pa.us>
Subject: Re: [HACKERS] PG_UPGRADE status?
In-Reply-To: <37D6E08F.34A1559E@wgcr.org> from Lamar Owen at "Sep 8,
1999 06:17:52 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Wed, 8 Sep 1999 18:34:40 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Reference my message to Tom Lane. Yes, such a program would be hard --
but most of it is already written and available in CVS -- thank God for
CVS! -- all that's needed is to extract the storage managers for each
major version, extract the reading code, etc, to get the on-disk
representation to an intermediate in memory form, then write it out with
the latest and greatest storage manager (into a different file, of
course, until the upgrade is finished). Unless I badly misunderstand
the way PostgreSQL does things, that should work -- but I may not have
expressed it the same way I see it in my mind.
Do a cost/benefit analysis on that one. :-)
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Sep 8 18: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 SAA22827
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 18:41:53 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA01424;
Wed, 8 Sep 1999 18:40:38 -0400 (EDT)
To: Michael Simms <grim@argh.demon.co.uk>
cc: ramirez@doc.mssm.edu (Edwin Ramirez),
pgsql-hackers@postgreSQL.org (PostgreSQL-development)
Subject: Re: [HACKERS] Postgres Performance
In-reply-to: Your message of Wed, 8 Sep 1999 22:41:04 +0100 (BST)
<199909082141.WAA00576@argh.demon.co.uk>
Date: Wed, 08 Sep 1999 18:40:37 -0400
Message-ID: <1422.936830437@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Simms <grim@argh.demon.co.uk> writes:
If I do a large search the first time is about three times slower than
any subsequent overlapping (same data) searches. I would like to always
get the higher performance.
What happens the first time is that it must read the data off the disc. After
that the data comes from memory IF it is cached. Disc read will always be
slower with current disc technology.
There is that effect, but I suspect Edwin may also be seeing another
effect. When a tuple is first inserted or modified, it is written into
the table with a marker saying (in effect) "Inserted by transaction NNN,
not committed yet". To find out whether the tuple is really any good,
you have to go and consult pg_log to see if that transaction got
committed. Obviously, that's slow, so the first subsequent transaction
that does so and finds that NNN really did get committed will rewrite
the disk page with the tuple's state changed to "Known committed".
So, the first select after an update transaction will spend additional
cycles checking pg_log and marking committed tuples. In effect, it's
doing the last phase of the update. We could instead force the update
to do all its own housekeeping, but the overall result wouldn't be any
faster; probably it'd be slower.
I would imagine (Im not an expert, but through observation) that if
you drasticly increase the number of shared memory buffers, then when
you startup your front-end simply do a select * from the tables, it
may even keep them all in memory from the start.
The default buffer space (64 disk pages) is not very large --- use
a larger -B setting if you have the memory to spare.
regards, tom lane
From bouncefilter Wed Sep 8 18:48:34 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA23535
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 18:47:42 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id SAA27668;
Wed, 8 Sep 1999 18:40:52 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909082240.SAA27668@candle.pha.pa.us>
Subject: Re: [HACKERS] PG_UPGRADE status
In-Reply-To: <1377.936829369@sss.pgh.pa.us> from Tom Lane at "Sep 8,
1999 06:22:49 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 8 Sep 1999 18:40:52 -0400 (EDT)
CC: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
The issue with MVCC is that the state of a tuple isn't solely determined
by what is in the disk file for its table; you have to also consult
pg_log to see whether recent transactions have been committed or not.
pg_upgrade doesn't import the old pg_log into the new database (and
can't very easily, since the new database will have its own), so there's
a problem with recent tuples possibly getting lost.OTOH, it seems to me that this was true in older releases as well
(pg_log has always been critical data), so I guess I'm not clear on
why pg_upgrade worked at all, ever...
At the end of pg_upgrade, there are the lines:
mv -f $OLDDIR/pg_log data
mv -f $OLDDIR/pg_variable data
echo "You may remove the $OLDDIR directory with 'rm -r $OLDDIR'."
exit 0
This is used to get the proper transaction status into the new
installation. Is the VACUUM added to pg_upgrade necessary?
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Sep 8 20:30:35 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA37147
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 20:30: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 UAA01728;
Wed, 8 Sep 1999 20:27:33 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PG_UPGRADE status
In-reply-to: Your message of Wed, 8 Sep 1999 18:40:52 -0400 (EDT)
<199909082240.SAA27668@candle.pha.pa.us>
Date: Wed, 08 Sep 1999 20:27:33 -0400
Message-ID: <1726.936836853@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
pg_upgrade doesn't import the old pg_log into the new database (and
can't very easily, since the new database will have its own), so there's
a problem with recent tuples possibly getting lost.
At the end of pg_upgrade, there are the lines:
mv -f $OLDDIR/pg_log data
mv -f $OLDDIR/pg_variable data
This is used to get the proper transaction status into the new
installation. Is the VACUUM added to pg_upgrade necessary?
I'm sorry, I had that backwards (knew I shoulda checked the code).
pg_upgrade *does* overwrite the destination pg_log, and what that
means is that incoming tuples in user relations should be fine.
What's at risk is recently-committed tuples in the system relations,
notably the metadata that pg_upgrade has just inserted for those
user relations.
The point of the VACUUM is to try to ensure that everything
in the system relations is marked as certainly committed (or
certainly dead) before we discard the pg_log information.
I don't recall ever hearing from Vadim about whether that
is a trustworthy way of doing it, however.
One thing that occurs to me just now is that we probably need
to vacuum *each* database in the new installation. The patch
I added to pg_dump doesn't do the job because it only vacuums
whichever database was dumped last by pg_dumpall...
regards, tom lane
From bouncefilter Wed Sep 8 21:41:37 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA46115
for <pgsql-hackers@postgresql.org>; Wed, 8 Sep 1999 21:40:33 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id CAA11936;
Thu, 9 Sep 1999 02:43:50 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909090143.CAA11936@argh.demon.co.uk>
Subject: Vacuum analyze bug CAUGHT
To: pgsql-hackers@postgresql.org
Date: Thu, 9 Sep 1999 02:43:50 +0100 (BST)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi
Okee, I have caught the vacuum analyse crash that was giving me a load of
grief
Firstly, I create the following database
$psql crashtest
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.1 on i586-pc-linux-gnu, compiled by gcc -ggdb ]
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: crashtest
crashtest=> select version();
version
-------------------------------------------------------------
PostgreSQL 6.5.1 on i586-pc-linux-gnu, compiled by gcc -ggdb
(1 row)
crashtest=> \d
Database = crashtest
+------------------+----------------------------------+----------+
| Owner | Relation | Type |
+------------------+----------------------------------+----------+
| test | testtable | table |
+------------------+----------------------------------+----------+crashtest=> select distinct * from testtable;
vara|varb
----+----
abc |def
(1 row)
crashtest=> select count(*) from testtable;
count
------
319800
(1 row)
-----------------------------------
Now, I then create a text file with 780 (just a random large number) new
lines that are exactly the same as the ones already in the database, so they
can be added with the copy command.
(the 319,800 rows I have in my database were actually created using copy
of this file, but I think that that is irrelavent).
I then run the followiung script (which you will note just runs forever:
------------------------------------------------------
#!/bin/sh -
(
while [ "1" = "1" ]
do
echo "create temp table temptest ( vara text, varb text );"
echo "copy temptest from '/tmp/copyeffort';"
echo "insert into testtable select * from temptest;"
echo "drop table temptest;"
sleep 1
done
) | psql crashtest
-----------------------------------------------------
I attach gdb to the backend that is handling this task
I then start a psql session to the same database
Then I attach another GDB to this backend too, so I have GDB on both
Then, in psql, I run and get the following result:
-----------
crashtest=> vacuum analyze;
NOTICE: Rel pg_type: TID 4/3: InsertTransactionInProgress 129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/5: InsertTransactionInProgress 129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/6: InsertTransactionInProgress 129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/7: InsertTransactionInProgress 129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/8: InsertTransactionInProgress 129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/9: InsertTransactionInProgress 129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/10: InsertTransactionInProgress 129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/11: InsertTransactionInProgress 129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/12: InsertTransactionInProgress 129915 - can't shrink relation
NOTICE: Rel pg_class: TID 3/22: InsertTransactionInProgress 129915 - can't shrink relation
NOTICE: AbortTransaction and not in in-progress state
------------
At this point, the backend attatched to the script doing the creates inserts
and drops has the following:
Program received signal SIGUSR2, User defined signal 2.
0x4018db4d in __libc_fsync ()
(gdb) where
#0 0x4018db4d in __libc_fsync ()
#1 0x80d5908 in pg_fsync (fd=3) at fd.c:202
#2 0x80d615a in FileSync (file=3) at fd.c:876
#3 0x80dc9ed in mdcommit () at md.c:796
#4 0x80dd1bc in smgrcommit () at smgr.c:375
#5 0x80d47f7 in FlushBufferPool (StableMainMemoryFlag=0) at bufmgr.c:1260
#6 0x8078755 in RecordTransactionCommit () at xact.c:636
#7 0x8078919 in CommitTransaction () at xact.c:940
#8 0x8078ac1 in CommitTransactionCommand () at xact.c:1177
#9 0x80df0cf in PostgresMain (argc=-1073742286, argv=0xbffff7a0, real_argc=7,
real_argv=0xbffffd04) at postgres.c:1679
#10 0x80c91ba in DoBackend (port=0x81ea4a0) at postmaster.c:1628
#11 0x80c8cda in BackendStartup (port=0x81ea4a0) at postmaster.c:1373
#12 0x80c8429 in ServerLoop () at postmaster.c:823
#13 0x80c7f67 in PostmasterMain (argc=7, argv=0xbffffd04) at postmaster.c:616
#14 0x80a0986 in main (argc=7, argv=0xbffffd04) at main.c:97
#15 0x400fccb3 in __libc_start_main (main=0x80a0920 <main>, argc=7,
argv=0xbffffd04, init=0x8061360 <_init>, fini=0x810d63c <_fini>,
rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffcfc)
at ../sysdeps/generic/libc-start.c:78
(gdb)
Program received signal SIGUSR2, User defined signal 2.
0x4018db4d in __libc_fsync ()
(gdb) where
#0 0x4018db4d in __libc_fsync ()
#1 0x80d5908 in pg_fsync (fd=3) at fd.c:202
#2 0x80d615a in FileSync (file=3) at fd.c:876
#3 0x80dc9ed in mdcommit () at md.c:796
#4 0x80dd1bc in smgrcommit () at smgr.c:375
#5 0x80d47f7 in FlushBufferPool (StableMainMemoryFlag=0) at bufmgr.c:1260
#6 0x8078755 in RecordTransactionCommit () at xact.c:636
#7 0x8078919 in CommitTransaction () at xact.c:940
#8 0x8078ac1 in CommitTransactionCommand () at xact.c:1177
#9 0x80df0cf in PostgresMain (argc=-1073742286, argv=0xbffff7a0, real_argc=7,
real_argv=0xbffffd04) at postgres.c:1679
#10 0x80c91ba in DoBackend (port=0x81ea4a0) at postmaster.c:1628
#11 0x80c8cda in BackendStartup (port=0x81ea4a0) at postmaster.c:1373
#12 0x80c8429 in ServerLoop () at postmaster.c:823
#13 0x80c7f67 in PostmasterMain (argc=7, argv=0xbffffd04) at postmaster.c:616
#14 0x80a0986 in main (argc=7, argv=0xbffffd04) at main.c:97
#15 0x400fccb3 in __libc_start_main (main=0x80a0920 <main>, argc=7,
argv=0xbffffd04, init=0x8061360 <_init>, fini=0x810d63c <_fini>,
rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffcfc)
at ../sysdeps/generic/libc-start.c:78
(gdb)
About 3 - 5 seconds later, the gdb attached to the vacuuming psql gets the
following - Bear in mind this is a DIFFERENT BACKEND
Program received signal SIGSEGV, Segmentation fault.
AllocSetReset (set=0x0) at aset.c:159
aset.c:159: No such file or directory.
(gdb) where
#0 AllocSetReset (set=0x0) at aset.c:159
#1 0x810ac12 in EndPortalAllocMode () at portalmem.c:938
#2 0x8078833 in AtAbort_Memory () at xact.c:800
#3 0x80789ff in AbortTransaction () at xact.c:1026
#4 0x8078aef in AbortCurrentTransaction () at xact.c:1243
#5 0x80deed6 in PostgresMain (argc=-1073742288, argv=0xbffff7a0, real_argc=7,
real_argv=0xbffffd04) at postgres.c:1550
#6 0x80c91ba in DoBackend (port=0x81ea4a0) at postmaster.c:1628
#7 0x80c8cda in BackendStartup (port=0x81ea4a0) at postmaster.c:1373
#8 0x80c8429 in ServerLoop () at postmaster.c:823
#9 0x80c7f67 in PostmasterMain (argc=7, argv=0xbffffd04) at postmaster.c:616
#10 0x80a0986 in main (argc=7, argv=0xbffffd04) at main.c:97
#11 0x400fccb3 in __libc_start_main (main=0x80a0920 <main>, argc=7,
argv=0xbffffd04, init=0x8061360 <_init>, fini=0x810d63c <_fini>,
rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffcfc)
at ../sysdeps/generic/libc-start.c:78
(gdb)
------------------------------------------------------------------------
This is REPRODUCABLE
I have run this through 5 times and it only managed to vacuum two times.
Now, I have the two GDBs still running, so if you need any values such
as variable states, let me know and I will supply them. (I'll be out of
the house till about 7.30pm UK time tomorrow, so it will have to be after
then).
Hopefully, this will be something can get fixed for 6.5.2 as it is a BIG
problem for me, as it happens when I am building my postgresql search
engine.
Thanks
M Simms
From bouncefilter Wed Sep 8 21:58:36 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id VAA53604
for pgsql-hackers@postgresql.org; Wed, 8 Sep 1999 21:58:19 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: "Damond Walker" <dwalker@iximd.com>
X-Newsgroups: comp.databases.postgresql.hackers
Subject: Sparc stuff again.
Lines: 9
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID: <wxEB3.600$es3.115790@typhoon1.gnilink.net>
Date: Thu, 09 Sep 1999 02:01:00 GMT
X-Trace: typhoon1.gnilink.net 936842460 151.196.99.113 (Wed,
08 Sep 1999 22:01:00 EDT)
To: pgsql-hackers@postgresql.org
Alright, I managed to find out why PostgreSQL dies when run on my Sparc.
Seems it's hitting a function called tas() and never exiting (that's what
gdb postmaster <id> is showing from the backtrace anyway). I've managed to
find about three or so different places where tas() is defined (using
assembler). Does anyone have a patch that I can apply to fix this behavior?
Damo
From bouncefilter Wed Sep 8 23:12:44 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA62745
for <pgsql-hackers@postgreSQL.org>; Wed, 8 Sep 1999 23:12:23 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id XAA03261;
Wed, 8 Sep 1999 23:07:59 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909090307.XAA03261@candle.pha.pa.us>
Subject: Re: [HACKERS] PG_UPGRADE status
In-Reply-To: <1726.936836853@sss.pgh.pa.us> from Tom Lane at "Sep 8,
1999 08:27:33 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 8 Sep 1999 23:07:59 -0400 (EDT)
CC: Lamar Owen <lamar.owen@wgcr.org>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
pg_upgrade *does* overwrite the destination pg_log, and what that
means is that incoming tuples in user relations should be fine.
What's at risk is recently-committed tuples in the system relations,
notably the metadata that pg_upgrade has just inserted for those
user relations.The point of the VACUUM is to try to ensure that everything
in the system relations is marked as certainly committed (or
certainly dead) before we discard the pg_log information.
I don't recall ever hearing from Vadim about whether that
is a trustworthy way of doing it, however.One thing that occurs to me just now is that we probably need
to vacuum *each* database in the new installation. The patch
I added to pg_dump doesn't do the job because it only vacuums
whichever database was dumped last by pg_dumpall...
I see what you are saying now. pg_upgrade basically replaces the system
tables, but keeps the user data and pg_log. So, if you do initdb, and
create your user table, then recover the user data tables and pg_log,
and if pg_log has a transaction marked as aborted that has the same
number as one of the user create table statements, it would not see the
table. I see why the vacuum is needed.
I wrote pg_upgrade as an attempt to do upgrades without dumping. I
heard so little about it when it was introduced, I thought it was not
really being used. When I disabled it for 6.5, I found out how many
people were using it without incident.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Sep 9 12:53:46 1999
Received: from mail_dns.lagoon.nc (mail.offratel.nc [209.58.55.28])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA70530;
Thu, 9 Sep 1999 12:53:14 -0400 (EDT)
(envelope-from fillons@offratel.nc)
Received: from portable (unverified [209.58.55.145]) by mail_dns.lagoon.nc
(Rockliffe SMTPRA 3.4.3) with SMTP id <B0000034438@mail_dns.lagoon.nc>;
Fri, 10 Sep 1999 03:54:56 +1100
Message-ID: <000001befae3$d96d6d20$91373ad1@portable>
From: "=?iso-8859-1?Q?St=E9phane_FILLON?=" <fillons@offratel.nc>
To: "pgsql-hackers" <pgsql-hackers@postgresql.org>,
"pgsql-general" <pgsql-general@postgresql.org>,
"pgsql-admin" <pgsql-admin@postgresql.org>
Subject: How to use pg_log ?
Date: Thu, 9 Sep 1999 19:14:40 +1100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_004E_01BEFAF7.90E2C780"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
This is a multi-part message in MIME format.
------=_NextPart_000_004E_01BEFAF7.90E2C780
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi !
I would like to know our I can read the log file.
Is it the file where I can detail all the transactions ?
Regards,
Stephane FILLON
------=_NextPart_000_004E_01BEFAF7.90E2C780
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hi !</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>I would like to know our I can read =
the log=20
file.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Is it the file where I can detail =
all the=20
transactions ?</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Regards,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Stephane =
FILLON</FONT></DIV></BODY></HTML>
------=_NextPart_000_004E_01BEFAF7.90E2C780--
From bouncefilter Thu Sep 9 06:57:42 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id GAA23521
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 06:57:31 -0400 (EDT)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11P1pG-0003kLC; Thu, 9 Sep 99 12:53 MET DST
Message-Id: <m11P1pG-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Problem enabling pltcl
To: lamar.owen@wgcr.org (Lamar Owen)
Date: Thu, 9 Sep 1999 12:53:10 +0200 (MET DST)
Cc: patrickdlogan@home.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <37D69D22.8876C0C4@wgcr.org> from "Lamar Owen" at Sep 8,
99 01:30:10 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Patrick Logan wrote:
ERROR: Unrecognized language specified in a CREATE FUNCTION:
'pltcl'. Recognized languages are sql, C, internal and the
created procedural languages.The docs say that pltcl is enabled if it is built with the TCL
option. What am I missing?CREATE LANGUAGE (command line utility 'createlang'). See the regression
test shell script (src/test/regress/regress.sh) for an example using
plpgsql. The PL's are not created and installed by default, apparently.
Yepp - it's a doc mistake because first I made it that way
and we decided later not to install by default into template1
and provide createlang instead.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Thu Sep 9 07:03:42 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id HAA24089;
Thu, 9 Sep 1999 07:03:01 -0400 (EDT) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-docs@postgreSQL.org
id m11P1uq-0003kLC; Thu, 9 Sep 99 12:58 MET DST
Message-Id: <m11P1uq-0003kLC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: Problem enabling pltcl
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Thu, 9 Sep 1999 12:58:56 +0200 (MET DST)
Cc: patrickdlogan@home.com, pgsql-hackers@postgreSQL.org,
pgsql-docs@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <1240.936826965@sss.pgh.pa.us> from "Tom Lane" at Sep 8,
99 05:42:45 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text
Tom Lane wrote:
But if the install process were to install pltcl into template1 just
because you had chosen to build pltcl, then you'd lose the option of
only having it in some of your databases.
You still have that option even if it is installed in
template1. But you must do it the other way round and use
destroydb on the databases where you don't want it :-)
Bottom line: I think the install process is correct as is, but the docs
need to be updated to mention these considerations.
The docs where right for a short time during v6.5
development.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
From bouncefilter Thu Sep 9 08:22:43 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 IAA32418
for <hackers@postgresql.org>; Thu, 9 Sep 1999 08:22:22 -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 MAA08738;
Thu, 9 Sep 1999 12:21:51 GMT
Sender: lockhart@hub.org
Message-ID: <37D7A65E.99EB081@alumni.caltech.edu>
Date: Thu, 09 Sep 1999 12:21:50 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@hub.org>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [COMMITTERS] pgsql/src/backend/lib (stringinfo.c)
References: <199909081631.MAA62048@hub.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Cope with versions of vsnprintf() written by people who
don't read man pages...
RETURN VALUE
If the output was truncated, the return value is -1,
otherwise it is the number of characters stored, not
including the terminating null.
Is this consistant with the behavior you see on Linux? It's a GNU
library thing...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Sep 9 08:37:43 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 IAA34353;
Thu, 9 Sep 1999 08:36:55 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id MAA08751;
Thu, 9 Sep 1999 12:33:15 GMT
Sender: lockhart@hub.org
Message-ID: <37D7A90A.CCEBF2D1@alumni.caltech.edu>
Date: Thu, 09 Sep 1999 12:33:14 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: patrickdlogan@home.com
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
pgsql-docs@postgreSQL.org
Subject: Re: [HACKERS] Re: Problem enabling pltcl
References: <1240.936826965@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bottom line: I think the install process is correct as is, but the docs
need to be updated to mention these considerations.
Any takers? Look in doc/src/sgml/*.sgml for the doc sources; usually
grepping for a phrase is enough to figure out which source file you
need to change.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Sep 9 09:45: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 JAA43478
for <hackers@postgresql.org>; Thu, 9 Sep 1999 09:45:39 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA06994;
Thu, 9 Sep 1999 09:44:36 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [COMMITTERS] pgsql/src/backend/lib (stringinfo.c)
In-reply-to: Your message of Thu, 09 Sep 1999 12:21:50 +0000
<37D7A65E.99EB081@alumni.caltech.edu>
Date: Thu, 09 Sep 1999 09:44:35 -0400
Message-ID: <6992.936884675@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Cope with versions of vsnprintf() written by people who
don't read man pages...
RETURN VALUE
If the output was truncated, the return value is -1,
otherwise it is the number of characters stored, not
including the terminating null.
Is this consistant with the behavior you see on Linux? It's a GNU
library thing...
That is the behavior I saw on my Linux box, but the manpage installed
on the same box sez that the return value is equal to the passed buffer
size if there's an overrun. Maybe the manpage is out of date.
Anyway, the fixed code copes with both conventions.
You'll need to re-initdb to get rid of the broken rules in your
database, but then things should be OK...
regards, tom lane
From bouncefilter Fri Sep 10 00:38:56 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 AAA62709
for <hackers@postgresql.org>; Fri, 10 Sep 1999 00:38:53 -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 OAA09899;
Thu, 9 Sep 1999 14:44:26 GMT
Sender: lockhart@hub.org
Message-ID: <37D7C7C9.B20E4B7E@alumni.caltech.edu>
Date: Thu, 09 Sep 1999 14:44:25 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [COMMITTERS] pgsql/src/backend/lib (stringinfo.c)
References: <6992.936884675@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Anyway, the fixed code copes with both conventions.
You'll need to re-initdb to get rid of the broken rules in your
database, but then things should be OK...
Things look great. Thanks!
btw, any problem with trimming the numeric test back to taking a few
seconds, perhaps up to 30 seconds? It takes *way* too long at the
moment...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Sep 9 10:46: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 KAA52642
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 10:46:30 -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 KAA07115;
Thu, 9 Sep 1999 10:45:36 -0400 (EDT)
To: Michael Simms <grim@argh.demon.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
In-reply-to: Your message of Thu, 9 Sep 1999 02:43:50 +0100 (BST)
<199909090143.CAA11936@argh.demon.co.uk>
Date: Thu, 09 Sep 1999 10:45:36 -0400
Message-ID: <7113.936888336@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Simms <grim@argh.demon.co.uk> writes:
Okee, I have caught the vacuum analyse crash that was giving me a load
of grief
I spent a good while last night trying to duplicate your report, but
couldn't on either current sources or latest REL6_5 branch. Maybe that
means we fixed the problem already --- but I think it's more likely that
there's a platform dependency involved, or some additional enabling
condition that you forgot to mention. So you'll have to keep poking
at it. However, I do have some comments and suggestions.
Starting at the end, the final crash:
Program received signal SIGSEGV, Segmentation fault.
AllocSetReset (set=0x0) at aset.c:159
aset.c:159: No such file or directory.
(gdb) where
#0 AllocSetReset (set=0x0) at aset.c:159
#1 0x810ac12 in EndPortalAllocMode () at portalmem.c:938
#2 0x8078833 in AtAbort_Memory () at xact.c:800
#3 0x80789ff in AbortTransaction () at xact.c:1026
#4 0x8078aef in AbortCurrentTransaction () at xact.c:1243
#5 0x80deed6 in PostgresMain (argc=-1073742288, argv=0xbffff7a0, real_argc=7,
real_argv=0xbffffd04) at postgres.c:1550
appears to be the same bug I alluded to before: memory allocation isn't
cleaned up properly if elog(ERROR) is executed outside a transaction.
I know how to fix this, and will do so before 6.5.2, but fixing it will
just prevent a coredump after an error has already occurred. What we
need to be looking for in your setup is the reason why an error is being
reported at all.
The first thing you can do is look to see what the error message is ---
it should be in the postmaster's stderr logfile, even though 6.5.* libpq
omits to display it because of the crash. Another useful thing would be
to set a breakpoint at elog() so that you can examine the context of the
error report. (Actually, since vacuum generates lots of elog(NOTICE)
and elog(DEBUG), the breakpoint had better be further down in elog,
perhaps where it's about to longjmp back to PostgresMain.)
BTW, VACUUM runs a separate transaction for each table it works on,
so although most of its work is done inside a transaction, there are
short intervals between tables where it's not in one. The error must
be getting reported during one of these intervals. That narrows things
down a lot.
Now, about the SIGUSR2. That's mighty suggestive, but it's not
necessarily an indication of a bug. There are two reasons why a
SIGUSR2 would be delivered to a backend. One is LISTEN/NOTIFY, which
I assume we can discount, since you'd have to have explicitly done it.
The other is that the SI message buffer manager sends a broadcast
SIGUSR2 to all the backends if it thinks its message buffer is getting
dangerously full --- presumably that's what you saw happening. So the
questions raised are (a) why is the buffer getting full, and (b) could
it have actually overflowed later, and if so did the overflow recovery
code work?
Background: the SI message buffer is a scheme for notifying backends
to discard cached copies of tuples from the system tables. Whenever
a backend modifies a tuple from the system tables, it has to send out
an SI ("shared cache invalidation") message telling the other backends
it has changed tuple X in table Y, so that they discard their
no-longer-accurate cached copies, if any. Messages in the buffer can be
discarded only after all active backends have read them. Stuff like
VACUUM tends to produce a lot of SI messages, but table
creation/deletion causes some too.
The SI buffer is global across an installation (one postmaster and its
children), *not* per-database, so even if you only had these two
backends connected to your crashtest database, they could have been
affected by anything that was going on in other databases belonging
to the same postmaster. Were there other backends alive at the time,
and if so what were they doing, or not doing?
If all the backends are busy, the SI buffer really shouldn't get
anywhere near full, although I suppose it could happen under extreme
conditions. The case where the buffer tends to fill is when one or
more backends are sitting idle, waiting for a client command. They'll
only read SI messages during transaction start (or, in 6.6, after
acquiring a lock), so an idle backend blocks the SI buffer from
emptying. The point of the SIGUSR2 broadcast is to kick-start idle
backends so that they will execute a transaction and receive their
SI messages.
I am guessing that you had an idle backend connected to some other
database of the same postmaster, so that the SI buffer was getting
full of the messages being generated by the VACUUM and table create/
delete processes. If you had no idle backends then we ought to look
for the reason for the SI buffer filling far enough to cause SIGUSR2;
but if you did then it's a normal condition.
BTW, if you have a backend stopped due to a gdb breakpoint or trap,
it's certainly not consuming SI messages. So when you left it sit after
observing the SIGUSR2, you altered the behavior. The VACUUM process was
still generating SI messages, and even though the hypothetical idle
backend would have eaten its messages thanks to SIGUSR2, the one you had
blocked with gdb stopped doing so. So eventually there would have been
an SI overflow condition. I think that would take longer than "3-5
seconds", though, unless your machine is way faster than mine.
If the SI buffer does overflow because someone isn't eating his messages
promptly, it's not supposed to be fatal. Rather, the SI manager
reports to all the backends "Sorry, I've lost track of what's going on,
so I suggest you discard *all* your cached tuples." However, 6.5.* has
some bugs in the shared cache reset process. (I think I have fixed these
for 6.6, but there are enough poorly-tested revisions in the affected
modules that we'd decided not to risk trying to back-patch 6.5.*.)
Anyway, back to the point: this is all very suggestive that maybe what
you are seeing is SI overflow and a consequent failure. But I'm not
convinced of it, partly because of the timing issue and partly because
the vacuum process would have issued a "NOTICE: SIReadEntryData: cache
state reset" message before entering the buggy code. I didn't see one
in your trace. However, if you find instances of this message in
your postmaster logfile, then it's definitely a possible cause.
(I would still wonder why SI overflow is occurring in the normal case
where you're not using gdb to block a backend from responding to
SIGUSR2.)
I hope this gives you enough info to poke at the problem more
intelligently.
Lastly, did you build with --enable-cassert? The assert checks slow things
down a little, but are often real helpful when looking for backend bugs.
regards, tom lane
From bouncefilter Thu Sep 9 11:57:46 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA62136
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 11:57:38 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA11179;
Thu, 9 Sep 1999 11:51:16 -0400
Message-ID: <37D7D76D.591CF9F1@wgcr.org>
Date: Thu, 09 Sep 1999 11:51:09 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PG_UPGRADE status
References: <199909082240.SAA27668@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
At the end of pg_upgrade, there are the lines:
mv -f $OLDDIR/pg_log data
mv -f $OLDDIR/pg_variable dataecho "You may remove the $OLDDIR directory with 'rm -r $OLDDIR'."
exit 0This is used to get the proper transaction status into the new
installation. Is the VACUUM added to pg_upgrade necessary?
You know, up until this message I had the mistaken impression that
pg_upgrade was a C program... Boy was I wrong. And no wonder it's
hairy. I should have read the source first -- but nooo, I couldn't do
that. Open mouth, insert foot.
I _am_ contemplating a C version that would do far more than just
upgrades. I'm thinking of a pg_repair utility that could rebuild and
repair the on-disk structures. It would also facilitate database
recovery after a crash -- might be a real bear to do right. Comments?
Lamar Owen
From bouncefilter Thu Sep 9 12:02:45 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA62765
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 12:02:40 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA11191;
Thu, 9 Sep 1999 11:59:33 -0400
Message-ID: <37D7D95E.22D9377C@wgcr.org>
Date: Thu, 09 Sep 1999 11:59:26 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PG_UPGRADE status?
References: <1377.936829369@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Lamar Owen <lamar.owen@wgcr.org> writes:
Pipe or file, both versions have to be installed at the same time, so,
either way, it's messy.Er, no, that's the whole point. The easy way to attack this is
(1) While running old installation, pg_dumpall into a file.
(2) Shut down old postmaster, blow away old database files.
(3) Install new version, initdb, start new postmaster.
(4) Restore from pg_dump output file.
Would to God it were that easy! During an RPM upgrade, I have to
observer the following:
1.) The user types rpm -Uvh postgresql*.i386.rpm, or executes an upgrade
from an older RedHat version to a newer RedHat version.
2.) The first rpm's preinstall script starts running. The old version
of that rpm is still installed at this point, BUT I CAN'T EXECUTE ANY
DAEMONS -- the upgrade MIGHT be running in the wicked chroot environment
of the RedHat installer, with its restrictive set of commands. So, I
CANNOT start a postmaster, nor can I be assured that a postmaster is
running -- according to RedHat, since it could be running in the chroot
installer, I can't even run a ps to SEE if postmaster is running
(problems with a chrooted /proc...). Therefore, the preinstall script
CANNOT execute pg_dumpall. I can't even run a standalone backend --
postmaster MIGHT be running.... And, I can't test to see if I'm running
in the installer or not... ;-( The only thing I CAN do is check /tmp for
the lock file.
3.) Once the preinstall script is finished, rpm blows in the first rpm's
files. This of course overwrites the previous version.
4.) Once all files are blown in, the postinstall script can run. It has
the same restrictions that the preinstall script does, since the rpm
COULD be running in the chroot installer.
5.) Repeat 2-4 for the remainder of the rpms.
If it weren't for the restrictions, it wouldn't be too hard. I think I
have it mostly solved -- I just have to clean up some code and do
testing. I'm using a two-stage plan -- the preinstall of the main
package (which only contains clients, client libraries, and
documentation) detects whether an old version of PGDATA is there or
not. If it is, a backup of the PGDATA tree is performed. The hard part
there is making sure a backend isn't running -- I haven't figured out
how to reliably detect a running postmaster without /proc or ps. The
lock file would seem to be a reliable flag -- but, what if the last
invocation of postmaster crashed for some reason, left the lockfile, and
the user, on the next boot, decides to upgrade versions of RedHat....
Stage two is performed in the server package's startup script
(/etc/rc.d/init.d/postgresql) -- it detects the backup, cleans up
PGDATA, initdb's, dumps the data from the old PGDATA (with the old
binaries), and restores the data with the new binaries.
convert to the latest and greatest without a backend running? All of
the code to deal with any version is out there in CVS already.Go for it ;-).
For some reason, I just KNEW you'd say that :-). Given six months of
spare time, I probably could. But, in the meantime, people's databases
are getting farkled by rpm upgrades, so I have to solve the problem.
the latest version of a tuple anyway. Was this the issue with
pg_upgrade and MVCC, or am I misunderstanding it?The issue with MVCC is that the state of a tuple isn't solely determined
by what is in the disk file for its table; you have to also consult
pg_log to see whether recent transactions have been committed or not.
pg_upgrade doesn't import the old pg_log into the new database (and
can't very easily, since the new database will have its own), so there's
a problem with recent tuples possibly getting lost.
The behavior I'm describing for pg_upgrade (let me name my program
something different, for clarity, pg_data_uprev) is to take an old
PGDATA tree, and convert it to new format into a blank, non-initdbed
tree, and get a consistent new format PGDATA tree. Thus, there are no
existing files at all to worry with. Visualize a filter -- old-PGDATA
-> pg_data_uprev -> new-PGDATA, with no backends involved at all.
Lamar Owen
WGCR Internet Radio
From bouncefilter Thu Sep 9 12:32:45 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA67561
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 12:32:33 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA21165;
Thu, 9 Sep 1999 12:20:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909091620.MAA21165@candle.pha.pa.us>
Subject: Re: [HACKERS] PG_UPGRADE status
In-Reply-To: <37D7D76D.591CF9F1@wgcr.org> from Lamar Owen at "Sep 9,
1999 11:51:09 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Thu, 9 Sep 1999 12:20:28 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
You know, up until this message I had the mistaken impression that
pg_upgrade was a C program... Boy was I wrong. And no wonder it's
hairy. I should have read the source first -- but nooo, I couldn't do
that. Open mouth, insert foot.
Yes, a quick few hour hack to do a quick upgrade. Worked better than I
thought it would.
I _am_ contemplating a C version that would do far more than just
upgrades. I'm thinking of a pg_repair utility that could rebuild and
repair the on-disk structures. It would also facilitate database
recovery after a crash -- might be a real bear to do right. Comments?
A bear.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Sep 9 12:33:46 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA67597
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 12:32:47 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA21308;
Thu, 9 Sep 1999 12:26:15 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909091626.MAA21308@candle.pha.pa.us>
Subject: Re: [HACKERS] PG_UPGRADE status?
In-Reply-To: <37D7D95E.22D9377C@wgcr.org> from Lamar Owen at "Sep 9,
1999 11:59:26 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Thu, 9 Sep 1999 12:26:15 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
2.) The first rpm's preinstall script starts running. The old version
of that rpm is still installed at this point, BUT I CAN'T EXECUTE ANY
DAEMONS -- the upgrade MIGHT be running in the wicked chroot environment
of the RedHat installer, with its restrictive set of commands. So, I
CANNOT start a postmaster, nor can I be assured that a postmaster is
running -- according to RedHat, since it could be running in the chroot
installer, I can't even run a ps to SEE if postmaster is running
(problems with a chrooted /proc...). Therefore, the preinstall script
CANNOT execute pg_dumpall. I can't even run a standalone backend --
postmaster MIGHT be running.... And, I can't test to see if I'm running
in the installer or not... ;-( The only thing I CAN do is check /tmp for
the lock file.
This seems almost impossible to handle. I have enough trouble wrinting
PostgreSQL C code when I have total control over the environment.
BTW, you can check for a running backend by trying to telnet to the 5432
port, or trying to do a connection to the unix domain socket.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Sep 9 12:38:45 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 MAA68412
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 12:38:21 -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 MAA08286;
Thu, 9 Sep 1999 12:36:59 -0400 (EDT)
To: Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
In-reply-to: Your message of Thu, 09 Sep 1999 10:45:36 -0400
<7113.936888336@sss.pgh.pa.us>
Date: Thu, 09 Sep 1999 12:36:59 -0400
Message-ID: <8284.936895019@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I wrote:
appears to be the same bug I alluded to before: memory allocation isn't
cleaned up properly if elog(ERROR) is executed outside a transaction.
I know how to fix this, and will do so before 6.5.2, but fixing it will
just prevent a coredump after an error has already occurred.
Here is the patch to fix that problem; line numbers are for current,
but it should apply to 6.5.1 with small offsets.
Also: have you applied the vc_abort patch discussed a month ago (see
my post in pgsql-patches, 11 Aug)? If not, that could well be the
source of your troubles. You might want to just grab the 6.5.2-beta
tarball and apply this patch, or even better pull the current state
of the REL6_5_PATCHES branch from the CVS server.
regards, tom lane
*** src/include/utils/portal.h.orig Thu Jul 15 21:11:26 1999
--- src/include/utils/portal.h Thu Sep 9 11:59:00 1999
***************
*** 75,80 ****
--- 75,81 ----
extern void PortalDestroy(Portal *portalP);
extern void StartPortalAllocMode(AllocMode mode, Size limit);
extern void EndPortalAllocMode(void);
+ extern void PortalResetHeapMemory(Portal portal);
extern PortalVariableMemory PortalGetVariableMemory(Portal portal);
extern PortalHeapMemory PortalGetHeapMemory(Portal portal);*** src/backend/utils/mmgr/portalmem.c.orig Sat Jul 17 23:20:03 1999
--- src/backend/utils/mmgr/portalmem.c Thu Sep 9 11:59:36 1999
***************
*** 83,89 ****
static void CollectNamedPortals(Portal *portalP, int destroy);
static Portal PortalHeapMemoryGetPortal(PortalHeapMemory context);
static PortalVariableMemory PortalHeapMemoryGetVariableMemory(PortalHeapMemory context);
- static void PortalResetHeapMemory(Portal portal);
static Portal PortalVariableMemoryGetPortal(PortalVariableMemory context); /* ----------------
--- 83,88 ----
***************
*** 838,844 ****
* BadArg if mode is invalid.
* ----------------
*/
! static void
PortalResetHeapMemory(Portal portal)
{
PortalHeapMemory context;
--- 837,843 ----
* BadArg if mode is invalid.
* ----------------
*/
! void
PortalResetHeapMemory(Portal portal)
{
PortalHeapMemory context;
*** src/backend/access/transam/xact.c.orig Sun Sep 5 13:12:34 1999
--- src/backend/access/transam/xact.c Thu Sep 9 12:00:23 1999
***************
*** 694,712 ****
AtCommit_Memory()
{
Portal portal;
- MemoryContext portalContext; /* ----------------
! * Release memory in the blank portal.
! * Since EndPortalAllocMode implicitly works on the current context,
! * first make real sure that the blank portal is the selected context.
! * (This is probably not necessary, but seems like a good idea...)
* ----------------
*/
portal = GetPortalByName(NULL);
! portalContext = (MemoryContext) PortalGetHeapMemory(portal);
! MemoryContextSwitchTo(portalContext);
! EndPortalAllocMode();
/* ----------------
* Now that we're "out" of a transaction, have the
--- 694,706 ----
AtCommit_Memory()
{
Portal portal; /* ----------------
! * Release all heap memory in the blank portal.
* ----------------
*/
portal = GetPortalByName(NULL);
! PortalResetHeapMemory(portal);
/* ----------------
* Now that we're "out" of a transaction, have the
***************
*** 784,802 ****
AtAbort_Memory()
{
Portal portal;
- MemoryContext portalContext;
/* ----------------
! * Release memory in the blank portal.
! * Since EndPortalAllocMode implicitly works on the current context,
! * first make real sure that the blank portal is the selected context.
! * (This is ESSENTIAL in case we aborted from someplace where it wasn't.)
* ----------------
*/
portal = GetPortalByName(NULL);
! portalContext = (MemoryContext) PortalGetHeapMemory(portal);
! MemoryContextSwitchTo(portalContext);
! EndPortalAllocMode();
/* ----------------
* Now that we're "out" of a transaction, have the
--- 778,790 ----
AtAbort_Memory()
{
Portal portal; /* ----------------
! * Release all heap memory in the blank portal.
* ----------------
*/
portal = GetPortalByName(NULL);
! PortalResetHeapMemory(portal);
/* ----------------
* Now that we're "out" of a transaction, have the
From bouncefilter Thu Sep 9 12:50:46 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 MAA70293
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 12:50:27 -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 MAA08369;
Thu, 9 Sep 1999 12:49:25 -0400 (EDT)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PG_UPGRADE status
In-reply-to: Your message of Thu, 9 Sep 1999 12:20:28 -0400 (EDT)
<199909091620.MAA21165@candle.pha.pa.us>
Date: Thu, 09 Sep 1999 12:49:25 -0400
Message-ID: <8367.936895765@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I _am_ contemplating a C version that would do far more than just
upgrades. I'm thinking of a pg_repair utility that could rebuild and
repair the on-disk structures. It would also facilitate database
recovery after a crash -- might be a real bear to do right. Comments?
A bear.
Indeed, but also an incredibly valuable contribution if you can pull it
off. If you want to tackle this task, don't let us discourage you!
regards, tom lane
From bouncefilter Thu Sep 9 13:06:46 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 NAA72892
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 13:06: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 NAA08414;
Thu, 9 Sep 1999 13:05:02 -0400 (EDT)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] PG_UPGRADE status?
In-reply-to: Your message of Thu, 09 Sep 1999 11:59:26 -0400
<37D7D95E.22D9377C@wgcr.org>
Date: Thu, 09 Sep 1999 13:05:01 -0400
Message-ID: <8412.936896701@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Lamar Owen <lamar.owen@wgcr.org> writes:
2.) The first rpm's preinstall script starts running. The old version
of that rpm is still installed at this point, BUT I CAN'T EXECUTE ANY
DAEMONS -- the upgrade MIGHT be running in the wicked chroot environment
of the RedHat installer, with its restrictive set of commands. So, I
CANNOT start a postmaster, nor can I be assured that a postmaster is
running -- according to RedHat, since it could be running in the chroot
installer, I can't even run a ps to SEE if postmaster is running
(problems with a chrooted /proc...). Therefore, the preinstall script
CANNOT execute pg_dumpall.
chroot? Where are you chrooted to? It would seem from your description
that neither the preinstall nor postinstall scripts can even see the
/usr/local/pgsql directory tree, which would make it impossible to do
anything --- and would be an incredibly stupid way to design an
installer system, so I have to assume I'm misreading what you wrote.
Also, if the pre/postinstall scripts cannot contact existing processes,
then there is no hope of killing/restarting any kind of daemon process,
not just Postgres in particular. The restrictions you claim are there
would make RPMs unusable for upgrading *anything* that has a
continuously running server process. Is Red Hat really that far out
in left field?
I can't even run a standalone backend --
postmaster MIGHT be running.... And, I can't test to see if I'm running
in the installer or not... ;-( The only thing I CAN do is check /tmp for
the lock file.
chroot would generally imply that you can't see the regular /tmp dir,
either.
regards, tom lane
From bouncefilter Thu Sep 9 13:53:47 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA79070
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 13:53:32 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id NAA00438;
Thu, 9 Sep 1999 13:50:12 -0400
Message-ID: <37D7F352.ABEBDA1D@wgcr.org>
Date: Thu, 09 Sep 1999 13:50:10 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: RPM restrictions (was:Re: [HACKERS] PG_UPGRADE status?)
References: <8412.936896701@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Lamar Owen <lamar.owen@wgcr.org> writes:
DAEMONS -- the upgrade MIGHT be running in the wicked chroot environment
of the RedHat installer, with its restrictive set of commands. So, I
chroot? Where are you chrooted to? It would seem from your description
that neither the preinstall nor postinstall scripts can even see the
/usr/local/pgsql directory tree, which would make it impossible to do
anything --- and would be an incredibly stupid way to design an
installer system, so I have to assume I'm misreading what you wrote.
I think you are misreading what I wrote, which is not at all surprising
-- it took me awhile to grok it.
No, during the installation of a version of RedHat Linux, the installer
(which boots off of either a floppy set or a virtual El Torito image on
CD) installs all the RPM's to the new root filesystem under chroot to
that new root filesystem. Thus, the real root is /dev/fd0 or whatever
the El Torito image's /dev entry is. The new root is mounted in a
directory off of the real root, and the rpm is installed with a chroot
to the new very incomplete root. Fortunately, PostgreSQL gets
installed down the list quite a ways, as P is after the halfway point.
To add to the confusion, there IS no /usr/local/pgsql -- RedHat has
munged the installation around to conform to the FSSTND for Linux --
meaning that the PostgreSQL binaries go in /usr/bin, the libraries go in
/usr/lib, the templates and other libraries that would ordinarily go in
PGLIB go in /usr/lib/pgsql, and PGDATA is /var/lib/pgsql. The goal is a
read-only /usr, but they are a little ways from that. And that is OK, as
RPM keeps a database of what file belongs to what package.
Also, if the pre/postinstall scripts cannot contact existing processes,
then there is no hope of killing/restarting any kind of daemon process,
not just Postgres in particular. The restrictions you claim are there
would make RPMs unusable for upgrading *anything* that has a
continuously running server process.
The restrictions are only on RPM's that ship as part of the Official
Boxed Set. RPM's are designed to be totally self-contained --
dependencies are rigorously specified (such as the PostgreSQL RPM's
dependency upon chkconfig to set the init sequence number), and
assumptions are nil. I can do very little in the pre and post scripts
-- making an offline backup of PGDATA and the essential executables and
libraries needed to restore the old PGDATA is the extent of it. Of
course, I then have to contend with the user who upgrades with
postmaster running....
To summarize: RPM's that ship as part of the RedHat Official Boxed Set
(OBS) (which PostgreSQL does), must contend with two very different
installation environments:
1.) The chroot installer at initial operating system install time, and
its OS upgrade alter ego;
2.) The environment of rpm -U, whether initiated by the user or by proxy
(such as AutoRPM), which is an entirely NORMAL environment where you can
do anything you want.
Other RPM's that do not ship as part of the OBS do not have the
restrictions of 1. However, being in the OBS is a very desireable
place, as that assures that ALL RedHat users have the opportunity to use
PostgreSQL -- and, in fact, PostgreSQL is the ONLY RDBMS RedHat is
shipping, giving us tremendous exposure.
Is Red Hat really that far out
in left field?
If you want to call it left field, yes, they are. RPM's are the HTML of
the package managers -- the author has little to no control over
presentation -- that is, package installation order, or, for that
matter, whether the install time scripts even get run (rpm --noscripts,
anyone...). It is a very _different_ environment.
chroot would generally imply that you can't see the regular /tmp dir,
either.
The mounted root /tmp is visible BECAUSE of the chroot in the installer
-- but Bruce's suggestion of connecting to port 5432 is a better idea.
Although, in the installer, I can't do that either... ;-(. I guess I
need to first detect whether we're in the installer or not. And RedHat
doesn't want me to be able to do that. Catch 22.
Thanks -- the discussion is helping me find holes in my strategy.
Lamar Owen
WGCR Internet Radio
From bouncefilter Thu Sep 9 14:58:47 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA86542
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 14:58:07 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
Received: from pop.dn.net (pm-81.ppp.wdc.dn.net [207.226.188.81])
by postal.dn.net (8.9.3/postal) with ESMTP id OAA22286
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 14:57:35 -0400 (EDT)
Sender: matuser@postal.dn.net
Message-ID: <37D808A3.3E840A7C@pop.dn.net>
Date: Thu, 09 Sep 1999 19:21:07 +0000
From: Bernard Frankpitt <frankpit@pop.dn.net>
Organization: AIMS
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.32 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: pgindent
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi All,
I just tried to get pgindent to work and I ran into a few snags
1)
I tried the src/tools/pgindent/indent.bsd.patch on two recent
versions of bsd indent. One from the current version of openbsd, and
one from freebsd RELENG_3. In neither case the patch applied cleanly.
The code in indent around the area of the second patch segment
*** 186,192 ****
*e_token++ = *buf_ptr++;
}
}
! if (*buf_ptr == 'L' || *buf_ptr == 'l')
*e_token++ = *buf_ptr++;
}
else
now looks like this
while (1) {
if (!(seensfx & 1) &&
(*buf_ptr == 'U' || *buf_ptr == 'u')) {
CHECK_SIZE_TOKEN;
*e_token++ = *buf_ptr++;
seensfx |= 1;
continue;
}
if (!(seensfx & 2) &&
(*buf_ptr == 'L' || *buf_ptr == 'l')) {
CHECK_SIZE_TOKEN;
if (buf_ptr[1] == buf_ptr[0])
*e_token++ = *buf_ptr++;
*e_token++ = *buf_ptr++;
seensfx |= 2;
continue;
}
break;
Without understanding what the code is meant to do, I am guessing that
the second patch is no longer necessary.
Also, in the openbsd source the specials buffer is automatically
resized, so it seems that neither part of the patch is necessary for
recent openbsd sources.
2)
I compiled and tried both bsd distributions. And ran into the
following problem with pgindent.
The test in pgindent for the gnu vesion doesn't work.
indent -version -npro </dev/null >/dev/null 2>&1
if [ "$?" -eq 0 ]
then echo "You appear to have GNU indent rather than BSD indent." >&2
echo "See the pgindent/README file for a description of its
problems." >
&2
EXTRA_OPTS="-ncdb -bli0 -npcs -cli4"
else echo "Hope you installed /src/tools/pgindent/indent.bsd.patch."
&2
EXTRA_OPTS="-bbb -cli1"
fi
I think that you need to use
indent --version -npro </dev/null >/dev/null 2>&1
On my system (Redhat Linux 5.?) I get
aims2-bernie:$ indent --version
GNU indent 1.9.1
aims2-bernie:$ echo $?
0
aims2-bernie:$ bsdindent --version
bsdindent: Command line: unknown parameter "--version"
aims2-bernie:$ echo $?
1
( That is with 'bsdindent' as the patched freebsd indent )
3)
Finally, the result of running
find . -name '*.[ch]' -type f -print | egrep -v '\+\+|/odbc/|s_lock.h'
| xargs -n100 pgindent
on a fresh copy of the 6.5 sources with either the openbsd or patched
bsd indent is the following
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
./backend/parser/gram.c
Error@5251: #if stack overflow
Error@5252: #if stack overflow
Error@5263: Unmatched #endif
Error@5264: Unmatched #endif
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
./interfaces/ecpg/test/header_test.h
Error@19: Stuff missing from end of file.
Are the errors normal or do I still not have a correctly working
version?
Bernie Frankpitt
From bouncefilter Thu Sep 9 15:39:48 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA93656
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 15:39:08 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id UAA25753;
Thu, 9 Sep 1999 20:42:36 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909091942.UAA25753@argh.demon.co.uk>
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Thu, 9 Sep 1999 20:42:36 +0100 (BST)
Cc: grim@argh.demon.co.uk (Michael Simms), pgsql-hackers@postgreSQL.org
In-Reply-To: <7113.936888336@sss.pgh.pa.us> from "Tom Lane" at Sep 09,
1999 10:45:36 AM
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The first thing you can do is look to see what the error message is ---
it should be in the postmaster's stderr logfile, even though 6.5.* libpq
omits to display it because of the crash.
Woops, I only redirected stdout. I will redirect stderr too. *2 minutes and
one crash later* Hmmm, nothing appears in the logs.
/usr/bin/postmaster -S -N 128 -B 256 -D/var/lib/pgsql/data > /tmp/postmasterout 2> /tmp/postmastererr
And nothing was in either log.
Another useful thing would be
to set a breakpoint at elog() so that you can examine the context of the
error report. (Actually, since vacuum generates lots of elog(NOTICE)
and elog(DEBUG), the breakpoint had better be further down in elog,
perhaps where it's about to longjmp back to PostgresMain.)BTW, VACUUM runs a separate transaction for each table it works on,
so although most of its work is done inside a transaction, there are
short intervals between tables where it's not in one. The error must
be getting reported during one of these intervals. That narrows things
down a lot.
<snip SI information>
Now, let me think for a moment:
Vacuum works on each table inside a transaction
The backend only reads the SI buffer when it starts a new transaction
What then happens if vacuum is vacuuming a BIG table (such as 300,000
lines) whilst another process is doing create and drop tables a lot.
Wouldnt the buffer fill up, as it was never starting a transaction
when vacuuming that big table?
However those were the only two backends active, it is a test
database on my home machine.
an SI overflow condition. I think that would take longer than "3-5
seconds", though, unless your machine is way faster than mine.
Ive got an AMD K62-400 with 128 MB mmeory, not slow but not roastingly
fast either.
I hope this gives you enough info to poke at the problem more
intelligently.Lastly, did you build with --enable-cassert? The assert checks slow things
down a little, but are often real helpful when looking for backend bugs.
Nope, I will recompile the new beta with this option, and post on the
progress. Thanks
M Simms
From bouncefilter Thu Sep 9 15:46:49 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA94829
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 15:46:44 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id PAA01295;
Thu, 9 Sep 1999 15:44:44 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909091944.PAA01295@candle.pha.pa.us>
Subject: Re: [HACKERS] pgindent
In-Reply-To: <37D808A3.3E840A7C@pop.dn.net> from Bernard Frankpitt at "Sep 9,
1999 07:21:07 pm"
To: Bernard Frankpitt <frankpit@pop.dn.net>
Date: Thu, 9 Sep 1999 15:44:44 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hi All,
I just tried to get pgindent to work and I ran into a few snags
}
}
! if (*buf_ptr == 'L' || *buf_ptr == 'l')
*e_token++ = *buf_ptr++;
}
while (1) {
if (!(seensfx & 1) &&
(*buf_ptr == 'U' || *buf_ptr == 'u')) {
CHECK_SIZE_TOKEN;
*e_token++ = *buf_ptr++;
seensfx |= 1;
Also, in the openbsd source the specials buffer is automatically
resized, so it seems that neither part of the patch is necessary for
recent openbsd sources.
Great. Your version looks nice. BSDI also has fixed the buffer size
problem, but it was easier to just send people a patch to apply, rather
than illegally sending out their changes.
I think that you need to use
indent --version -npro </dev/null >/dev/null 2>&1On my system (Redhat Linux 5.?) I get
aims2-bernie:$ indent --version
GNU indent 1.9.1
aims2-bernie:$ echo $?
0
aims2-bernie:$ bsdindent --version
bsdindent: Command line: unknown parameter "--version"
aims2-bernie:$ echo $?
1( That is with 'bsdindent' as the patched freebsd indent )
Good. OK, new test is:
indent --version </dev/null >/dev/null 2>&1
if [ "$?" -eq 0 ]
then echo "You do not appear to have 'indent' installed on your
system." >&2
exit 1
fi
3)
Finally, the result of running
find . -name '*.[ch]' -type f -print | egrep -v '\+\+|/odbc/|s_lock.h'
| xargs -n100 pgindenton a fresh copy of the 6.5 sources with either the openbsd or patched
bsd indent is the followingHope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
./backend/parser/gram.c
Error@5251: #if stack overflow
Error@5252: #if stack overflow
Error@5263: Unmatched #endif
Error@5264: Unmatched #endif
This is expected. Gram.c is generated from gram.y, so there is no real
need to indent it.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
Hope you installed /src/tools/pgindent/indent.bsd.patch.
./interfaces/ecpg/test/header_test.h
Error@19: Stuff missing from end of file.
I haven't seen the egcs problem. In this case, it is getting confused
by the inline SQL commands. No cause for concern.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Thu Sep 9 17:00:48 1999
Received: from academic.mssm.edu (academic.mssm.edu [146.203.1.9])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA04776
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 16:59:56 -0400 (EDT)
(envelope-from ramirez@doc.mssm.edu)
Received: from doc.mssm.edu (adwr44.mssm.edu [146.203.33.44])
by academic.mssm.edu (8.9.1/8.9.1) with ESMTP id QAA00434
for <pgsql-hackers@postgreSQL.org>; Thu, 9 Sep 1999 16:54:11 -0400 (EDT)
Message-ID: <37D81E09.DD07DB2D@doc.mssm.edu>
Date: Thu, 09 Sep 1999 16:52:25 -0400
From: Edwin Ramirez <ramirez@doc.mssm.edu>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Postgres Performance
References: <1422.936830437@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I believe that disk pages are 1k in linux systems, that would mean that
I am allocating 3M when using "postmaster -i -B 3096 -o -S 2048" and 2M
for sorting. That is very low.
However, some of the postgres processes have memory segments larger
than 3M (see bottom).
I would imagine (Im not an expert, but through observation) that if
you drasticly increase the number of shared memory buffers, then when
you startup your front-end simply do a select * from the tables, it
may even keep them all in memory from the start.
That's basically what I tried to do, but I am unable to specify a very
large number (it complained when I tried -B > ~3900). Do these buffer
contain the actual table data?
I understand that the OS is buffering the data read from disk, but
postgres is competing with all the other processes on the system. I
think that if postgres had a dedicated (user configurable) cache, like
Oracle, then users could configure the system/postgres better.
4:29pm up 83 days, 23:42, 5 users, load average: 0.00, 0.01, 0.00
75 processes: 74 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 0.1% user, 1.1% system, 0.0% nice, 98.7% idle
Mem: 128216K av, 98812K used, 29404K free, 67064K shrd, 18536K buff
Swap: 80288K av, 22208K used, 58080K free 14924K
cached
PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME
COMMAND
16633 postgres 0 0 26536 1384 1284 S 0 0.0 1.0 0:02
postmaster
18190 postgres 0 0 27708 3432 2720 S 0 0.0 2.6 0:00
postmaster
18303 postgres 0 0 27444 2728 2196 S 0 0.0 2.1 0:00
postmaster
18991 postgres 0 0 27472 2908 2392 S 0 0.0 2.2 0:00
postmaster
19154 postgres 0 0 27408 2644 2140 S 0 0.0 2.0 0:06
postmaster
19155 postgres 0 0 27428 2712 2188 S 0 0.0 2.1 0:00
postmaster
19157 postgres 0 0 27840 10M 10144 S 0 0.0 8.6 0:08
postmaster
19282 postgres 0 0 27560 3332 2732 S 0 0.0 2.5 0:11
postmaster
19335 postgres 0 0 27524 3112 2528 S 0 0.0 2.4 0:03
postmaster
19434 postgres 0 0 27416 2700 2192 S 0 0.0 2.1 0:00
postmaster
From bouncefilter Fri Sep 10 02:16:55 1999
Received: from scratchy.sysads.com (root@scratchy.sysads.com [203.167.0.17])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA74974;
Fri, 10 Sep 1999 02:16:29 -0400 (EDT) (envelope-from jbd@sysads.com)
Received: from jbd-laptop (laptop.sysads.com [208.155.152.46]) by
scratchy.sysads.com (8.9.0/8.8.3) with ESMTP id NAA10202;
Fri, 10 Sep 1999 13:59:17 +0800
Message-Id: <4.2.0.58.19990910141925.00965220@sysads.com>
X-Sender: jbd@sysads.com
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58
Date: Fri, 10 Sep 1999 14:25:47 +0800
To: =?iso-8859-1?Q?=22St=E9phane_FILLON=22?= <fillons@offratel.nc>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>,
"pgsql-general" <pgsql-general@postgreSQL.org>,
"pgsql-admin" <pgsql-admin@postgreSQL.org>
From: "Jacques B. Dimanche" <jbd@sysads.com>
Subject: Re: [ADMIN] How to use pg_log ?
In-Reply-To: <000001befae3$d96d6d20$91373ad1@portable>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by hub.org id CAA75006
At 07:14 PM 9/9/99 +1100, St�phane FILLON wrote:
I would like to know our I can read the log file.
Is it the file where I can detail all the transactions ?
Hmmm... I believe the pg_log is just for internal use of Postgres to track
the committed and uncommitted transactions. If you want to log your
transactions, the only way I can think of off hand is to put the debug
function on the backend. For instance, I might use something like the
following: (Using Unix in /etc/rc.d/rc.local)
su postgres -c "nohup /usr/local/pgsql/bin/postmaster -B 2048 -i -d 2 -D
/datadir >> /path/to logfile 2>&1 &"
The -d option is the one that turns on debugging so you can see the actual
transactions. However, it does get quite large on a frequently accessed
database. I would really only recommend it for debugging client
code. Though there most likely is a better way, as I only started using
Postgres and learning SQL, 6 hours ago.
Just for comments though, excellent Database, was able to make Postgres
function extensions within 30 minutes of tinkering with it. Kudos to all
the programmers. The code was extremely well documented and laid out.
Sincerely Yours,
Jacques Dimanche
VP of Research and Development
Tridel Technologies, Inc.
From bouncefilter Fri Sep 10 02:39:55 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 CAA78198
for <pgsql-hackers@postgreSQL.org>;
Fri, 10 Sep 1999 02:39:43 -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 PAA08127; Fri, 10 Sep 1999 15:39:34 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Michael Simms" <grim@argh.demon.co.uk>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Vacuum analyze bug CAUGHT
Date: Fri, 10 Sep 1999 15:42:53 +0900
Message-ID: <000a01befb57$b55ab5e0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <199909090143.CAA11936@argh.demon.co.uk>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Hi
Vacuum couldn't preserve consistency without locking.
I'm anxious about locking for system tables.
Hi
Okee, I have caught the vacuum analyse crash that was giving me a load of
grief
[snip]
Then, in psql, I run and get the following result:
-----------
crashtest=> vacuum analyze;
NOTICE: Rel pg_type: TID 4/3: InsertTransactionInProgress 129915
- can't shrink relation
NOTICE: Rel pg_attribute: TID 23/5: InsertTransactionInProgress
129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/6: InsertTransactionInProgress
129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/7: InsertTransactionInProgress
129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/8: InsertTransactionInProgress
129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/9: InsertTransactionInProgress
129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/10: InsertTransactionInProgress
129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/11: InsertTransactionInProgress
129915 - can't shrink relation
NOTICE: Rel pg_attribute: TID 23/12: InsertTransactionInProgress
129915 - can't shrink relation
NOTICE: Rel pg_class: TID 3/22: InsertTransactionInProgress
129915 - can't shrink relation
CREATE TABLE doesn't lock system tables till end of transaction.
It's a cause of these NOTICE messages.
Should we lock system tables till end of transaction ?
Moreover CREATE TABLE doesn't acquire any lock for pg_attribute
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
while tuples are inserted into pg_attribute.
Concurrent vacuum may corrupt pg_attribute.
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Fri Sep 10 02:50:55 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 CAA79562
for <pgsql-hackers@postgreSQL.org>;
Fri, 10 Sep 1999 02:50:24 -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 OAA26436;
Fri, 10 Sep 1999 14:49:59 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37D8AA16.8F767392@krs.ru>
Date: Fri, 10 Sep 1999 14:49:58 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
References: <000a01befb57$b55ab5e0$2801007e@cadzone.tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hiroshi Inoue wrote:
crashtest=> vacuum analyze;
NOTICE: Rel pg_type: TID 4/3: InsertTransactionInProgress 129915
- can't shrink relation
...
CREATE TABLE doesn't lock system tables till end of transaction.
It's a cause of these NOTICE messages.Should we lock system tables till end of transaction ?
No, if we allow DDL statements inside BEGIN/END
(in long transaction).
Moreover CREATE TABLE doesn't acquire any lock for pg_attribute
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
while tuples are inserted into pg_attribute.
Concurrent vacuum may corrupt pg_attribute.
Should be fixed!
Vadim
From bouncefilter Fri Sep 10 05:16:57 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 FAA00983
for <pgsql-hackers@postgreSQL.org>;
Fri, 10 Sep 1999 05:16:55 -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 SAA08198; Fri, 10 Sep 1999 18:16:26 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Vadim Mikheev" <vadim@krs.ru>
Cc: "Michael Simms" <grim@argh.demon.co.uk>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Vacuum analyze bug CAUGHT
Date: Fri, 10 Sep 1999 18:19:45 +0900
Message-ID: <000b01befb6d$9f4419c0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <37D8AA16.8F767392@krs.ru>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal
Hiroshi Inoue wrote:
crashtest=> vacuum analyze;
NOTICE: Rel pg_type: TID 4/3: InsertTransactionInProgress 129915
- can't shrink relation...
CREATE TABLE doesn't lock system tables till end of transaction.
It's a cause of these NOTICE messages.Should we lock system tables till end of transaction ?
No, if we allow DDL statements inside BEGIN/END
(in long transaction).Moreover CREATE TABLE doesn't acquire any lock for pg_attribute
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
while tuples are inserted into pg_attribute.
Concurrent vacuum may corrupt pg_attribute.Should be fixed!
Seems CREATE TABLE don't acquire any lock for pg_relcheck and
pg_attrdef as well as pg_attribute. There may be other pg_.......
Here is a patch.
This patch also removes UnlockRelation() in heap_destroy_with_catalog().
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
*** catalog/heap.c.orig Tue Sep 7 08:52:04 1999
--- catalog/heap.c Fri Sep 10 16:43:18 1999
***************
*** 547,552 ****
--- 547,553 ----
*/
Assert(rel);
Assert(rel->rd_rel);
+ LockRelation(rel, AccessExclusiveLock);
hasindex = RelationGetForm(rel)->relhasindex;
if (hasindex)
CatalogOpenIndices(Num_pg_attr_indices, Name_pg_attr_indices, idescs);
***************
*** 607,612 ****
--- 608,614 ----
dpp++;
}+ UnlockRelation(rel, AccessExclusiveLock);
heap_close(rel);
/*
***************
*** 1330,1336 ****
rel->rd_nonameunlinked = TRUE;
- UnlockRelation(rel, AccessExclusiveLock);
heap_close(rel);
--- 1332,1337 ----
***************
*** 1543,1553 ****
--- 1544,1556 ----
values[Anum_pg_attrdef_adbin - 1] =
PointerGetDatum(textin(attrdef->adbin));
values[Anum_pg_attrdef_adsrc - 1] =
PointerGetDatum(textin(attrdef->adsrc));
adrel = heap_openr(AttrDefaultRelationName);
+ LockRelation(adrel, AccessExclusiveLock);
tuple = heap_formtuple(adrel->rd_att, values, nulls);
CatalogOpenIndices(Num_pg_attrdef_indices, Name_pg_attrdef_indices,
idescs);
heap_insert(adrel, tuple);
CatalogIndexInsert(idescs, Num_pg_attrdef_indices, adrel, tuple);
CatalogCloseIndices(Num_pg_attrdef_indices, idescs);
+ UnlockRelation(adrel, AccessExclusiveLock);
heap_close(adrel); pfree(DatumGetPointer(values[Anum_pg_attrdef_adbin - 1]));
***************
*** 1606,1616 ****
--- 1609,1621 ----
values[Anum_pg_relcheck_rcbin - 1] =
PointerGetDatum(textin(check->ccbin));
values[Anum_pg_relcheck_rcsrc - 1] =
PointerGetDatum(textin(check->ccsrc));
rcrel = heap_openr(RelCheckRelationName);
+ LockRelation(rcrel, AccessExclusiveLock);
tuple = heap_formtuple(rcrel->rd_att, values, nulls);
CatalogOpenIndices(Num_pg_relcheck_indices, Name_pg_relcheck_indices,
idescs);
heap_insert(rcrel, tuple);
CatalogIndexInsert(idescs, Num_pg_relcheck_indices, rcrel, tuple);
CatalogCloseIndices(Num_pg_relcheck_indices, idescs);
+ UnlockRelation(rcrel, AccessExclusiveLock);
heap_close(rcrel);pfree(DatumGetPointer(values[Anum_pg_relcheck_rcname - 1]));
From bouncefilter Fri Sep 10 05:21:57 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id FAA01513
for <pgsql-hackers@postgreSQL.org>;
Fri, 10 Sep 1999 05:21:03 -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 RAA27216;
Fri, 10 Sep 1999 17:20:21 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37D8CD55.BF37A8F3@krs.ru>
Date: Fri, 10 Sep 1999 17:20:21 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org,
"Marc G. Fournier" <scrappy@hub.org>
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
References: <000b01befb6d$9f4419c0$2801007e@cadzone.tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hiroshi Inoue wrote:
...
Here is a patch.
This patch also removes UnlockRelation() in heap_destroy_with_catalog().
Marc, I would grant to Hiroshi full CVS access...
Vadim
From bouncefilter Fri Sep 10 09:48:22 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 JAA01141;
Fri, 10 Sep 1999 09:48:16 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id NAA11517;
Fri, 10 Sep 1999 13:47:35 GMT
Sender: lockhart@hub.org
Message-ID: <37D90BF6.A79FD095@alumni.caltech.edu>
Date: Fri, 10 Sep 1999 13:47:34 +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: renato barrios <renato.barrios@online.fr>,
Postgres Hackers List <hackers@postgresql.org>, pg-general@postgresql.org
Subject: Re: Query about postgres medical database
References: <37D8D5A8.2FD4015B@online.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I am physician and I am very interested by possibilities postgresql
could offer to medical information management, specially in undeveloped
countries.
In the userguide you speake about a medical database and I would want to
contact people responsable of this project.
I believe that this example was from the days when Postgres was
developing at Berkeley. I know that there are more recent projects
(one of our contributors is an administrator at a hospital) and the
best way to find out about current projects is to post a question to a
mailing list.
Does anyone have something going in the medical info area?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Fri Sep 10 10:23:17 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA04337
for <hackers@postgreSQL.org>; Fri, 10 Sep 1999 10:22:42 -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 KAA10043;
Fri, 10 Sep 1999 10:21:04 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql/src/backend/lib (stringinfo.c)
In-reply-to: Your message of Thu, 09 Sep 1999 14:44:25 +0000
<37D7C7C9.B20E4B7E@alumni.caltech.edu>
Date: Fri, 10 Sep 1999 10:21:04 -0400
Message-ID: <10041.936973264@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
btw, any problem with trimming the numeric test back to taking a few
seconds, perhaps up to 30 seconds? It takes *way* too long at the
moment...
I've been griping about the slowness of the numeric test since it was
put in. Even a 2x reduction in the time taken would be really helpful.
Jan?
regards, tom lane
From bouncefilter Fri Sep 10 10:24:17 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 KAA04453
for <pgsql-general@postgresql.org>;
Fri, 10 Sep 1999 10:23:44 -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 11PRb0-0006tq-00; Fri, 10 Sep 1999 18:24:10 +0400
Date: Fri, 10 Sep 1999 18:24:09 +0400 (MSD)
From: Oleg Broytmann <phd@emerald.netskate.ru>
Reply-To: phd2@earthling.net
To: renato barrios <renato.barrios@online.fr>
cc: PostgreSQL <pgsql-general@postgresql.org>
Subject: Re: [HACKERS] Re: Query about postgres medical database
In-Reply-To: <37D90BF6.A79FD095@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.04.9909101819060.26486-100000@emerald.netskate.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hello!
I work for Russian National Research Surgery Centre (www.med.ru). I have
a database of patient data on Novel server, and I am writing and debugging
programs to store the data in Postgres. The dedicated host is oper.med.ru.
But I do not see anything special about the data - for me it is just
data that can be stored, searched and retrieved.
On Fri, 10 Sep 1999, Thomas Lockhart wrote:
I am physician and I am very interested by possibilities postgresql
could offer to medical information management, specially in undeveloped
countries.
In the userguide you speake about a medical database and I would want to
contact people responsable of this project.I believe that this example was from the days when Postgres was
developing at Berkeley. I know that there are more recent projects
(one of our contributors is an administrator at a hospital) and the
best way to find out about current projects is to post a question to a
mailing list.Does anyone have something going in the medical info area?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Oleg.
----
Oleg Broytmann http://members.xoom.com/phd2/ phd2@earthling.net
Programmers don't die, they just GOSUB without RETURN.
From bouncefilter Fri Sep 10 10:31:18 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 KAA05088
for <pgsql-hackers@postgreSQL.org>;
Fri, 10 Sep 1999 10:30: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 KAA10087;
Fri, 10 Sep 1999 10:28:06 -0400 (EDT)
To: Michael Simms <grim@argh.demon.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
In-reply-to: Your message of Thu, 9 Sep 1999 20:42:36 +0100 (BST)
<199909091942.UAA25753@argh.demon.co.uk>
Date: Fri, 10 Sep 1999 10:28:06 -0400
Message-ID: <10085.936973686@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Simms <grim@argh.demon.co.uk> writes:
Now, let me think for a moment:
Vacuum works on each table inside a transaction
The backend only reads the SI buffer when it starts a new transaction
What then happens if vacuum is vacuuming a BIG table (such as 300,000
lines) whilst another process is doing create and drop tables a lot.
Wouldnt the buffer fill up, as it was never starting a transaction
when vacuuming that big table?
Yup, could happen. (I think it would take several hundred create/
drop cycles, but that's certainly possible during a long vacuum.)
That's why there's code to deal with the possibility of SI buffer
overrun.
But as I said, I'm not convinced you are dealing with an SI overrun
--- and the lack of messages about it seems to point away from that
theory. I brought it up because it was a possible area for trouble.regards, tom lane
From bouncefilter Fri Sep 10 11:03:18 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 LAA10405
for <pgsql-hackers@postgreSQL.org>;
Fri, 10 Sep 1999 11:02:54 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA10355;
Fri, 10 Sep 1999 11:01:51 -0400 (EDT)
To: Edwin Ramirez <ramirez@doc.mssm.edu>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Postgres Performance
In-reply-to: Your message of Thu, 09 Sep 1999 16:52:25 -0400
<37D81E09.DD07DB2D@doc.mssm.edu>
Date: Fri, 10 Sep 1999 11:01:51 -0400
Message-ID: <10353.936975711@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Edwin Ramirez <ramirez@doc.mssm.edu> writes:
I believe that disk pages are 1k in linux systems, that would mean that
I am allocating 3M when using "postmaster -i -B 3096 -o -S 2048" and 2M
for sorting. That is very low.
No, buffers are 8K apiece (unless you've changed the BLCKSZ constant in
config.h). So -B 3096 means 24 meg of buffer space. The -S number is
indeed measured in kilobytes, however.
However, some of the postgres processes have memory segments larger
than 3M (see bottom).
'top' does not show shared memory segments AFAIK, and the buffer area is
a shared memory segment. Try "ipcs -m -a" to see what's going on in
shared memory.
That's basically what I tried to do, but I am unable to specify a very
large number (it complained when I tried -B > ~3900).
You're probably running into a configuration limit of your kernel ---
at a guess, your kernel is configured not to give out shared memory
segments exceeding 32Mb.
I understand that the OS is buffering the data read from disk, but
postgres is competing with all the other processes on the system. I
think that if postgres had a dedicated (user configurable) cache, like
Oracle, then users could configure the system/postgres better.
The shared-buffer cache does serve that purpose...
regards, tom lane
From bouncefilter Fri Sep 10 11:22:18 1999
Received: from ritchie.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA11786;
Fri, 10 Sep 1999 11:22:02 -0400 (EDT)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by ritchie.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id TAA18227;
Fri, 10 Sep 1999 19:21:56 +0400 (MSK/MSD)
X-Real-To: renato.barrios@online.fr
Received: (from dms@localhost)
by woland.wplus.net (8.9.2/8.9.1/wplus.2) id TAA08900;
Fri, 10 Sep 1999 19:21:55 +0400 (MSD)
Message-ID: <XFMail.990910192155.dms@wplus.net>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <37D90BF6.A79FD095@alumni.caltech.edu>
Date: Fri, 10 Sep 1999 19:21:55 +0400 (MSD)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: RE: [HACKERS] Re: Query about postgres medical database
Cc: pg-general@postgresql.org, Postgres Hackers List <hackers@postgresql.org>,
renato barrios <renato.barrios@online.fr>
On 10-Sep-99 Thomas Lockhart wrote:
I am physician and I am very interested by possibilities postgresql
could offer to medical information management, specially in undeveloped
countries.
In the userguide you speake about a medical database and I would want to
contact people responsable of this project.I believe that this example was from the days when Postgres was
developing at Berkeley. I know that there are more recent projects
(one of our contributors is an administrator at a hospital) and the
best way to find out about current projects is to post a question to a
mailing list.Does anyone have something going in the medical info area?
I was the maintainer/developer of postgresql based project for
City's Health department of St. Petersburg (RUSSIA),
This project includes financial part (medical insurance reports) and
numerouse statistical reports
(sex/age/diagnozis corellation, loads of different clinics and so on)
This project starts 1995 and it's succesfuly working now but without me ...
---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...
From bouncefilter Fri Sep 10 19:07:30 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 TAA46924
for <pgsql-hackers@postgreSQL.org>;
Fri, 10 Sep 1999 19:06:59 -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 TAA13454;
Fri, 10 Sep 1999 19:05:40 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Vadim Mikheev" <vadim@krs.ru>, "Michael Simms" <grim@argh.demon.co.uk>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
In-reply-to: Your message of Fri, 10 Sep 1999 18:19:45 +0900
<000b01befb6d$9f4419c0$2801007e@cadzone.tpf.co.jp>
Date: Fri, 10 Sep 1999 19:05:40 -0400
Message-ID: <13452.937004740@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
Moreover CREATE TABLE doesn't acquire any lock for pg_attribute
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
while tuples are inserted into pg_attribute.
Concurrent vacuum may corrupt pg_attribute.Should be fixed!
Seems CREATE TABLE don't acquire any lock for pg_relcheck and
pg_attrdef as well as pg_attribute. There may be other pg_.......
Here is a patch.
Hmm, do we really need to grab AccessExclusiveLock on the pg_ tables
while creating or deleting tables? That will mean no concurrency at
all for these operations. Seems to me we want AccessExclusiveLock on
the table being created or deleted, but something less strong on the
system tables. RowExclusiveLock might be appropriate --- Vadim, what
do you think?
Also, rather than running around and adding locks to every single
place that calls heap_open or heap_close, I wonder whether we shouldn't
have heap_open/heap_close themselves automatically grab or release
at least a minimal lock (AccessShareLock, I suppose).
Or maybe better: change heap_open/heap_openr/heap_close to take an
additional parameter specifying the kind of lock to grab. That'd still
mean having to visit all the call sites, but it would force people to
think about the issue in future rather than forgetting to lock a table
they're accessing.
Comments?
BTW, while I still haven't been able to reproduce Michael Simms' crash
reliably, I did see one coredump caused by an assert failure in
heap_delete():
#6 0x16181c in ExceptionalCondition (
conditionName=0x283d4 "!(( lp)->lp_flags & 0x01)", exceptionP=0x40009a80,
detail=0x0, fileName=0x7ae4 "\003", lineNumber=1121) at assert.c:72
#7 0x7cc18 in heap_delete (relation=0x400891c0, tid=0x402d962c, ctid=0x0)
at heapam.c:1121
#8 0x9c208 in DeleteAttributeTuples (rel=0x40535260) at heap.c:1118
#9 0x9c4dc in heap_destroy_with_catalog (
relname=0x4e4ed7 <Address 0x4e4ed7 out of bounds>) at heap.c:1310
#10 0xa5168 in RemoveRelation (
name=0x80db9380 <Address 0x80db9380 out of bounds>) at creatinh.c:157
#11 0x129760 in ProcessUtility (parsetree=0x402d8d28, dest=Remote)
at utility.c:215
This was in the process doing table creates/drops, and I surmise that
the problem was a tuple move executed concurrently by the process doing
VACUUM. In other words, it looks like this problem of missing lock
operations might be the cause, or one cause, of Michael's symptoms.
regards, tom lane
From bouncefilter Fri Sep 10 19:50:30 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 TAA51768
for <pgsql-hackers@postgreSQL.org>;
Fri, 10 Sep 1999 19:49:55 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA13512;
Fri, 10 Sep 1999 19:48:40 -0400 (EDT)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>, "Vadim Mikheev" <vadim@krs.ru>,
"Michael Simms" <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
In-reply-to: Your message of Fri, 10 Sep 1999 19:05:40 -0400
<13452.937004740@sss.pgh.pa.us>
Date: Fri, 10 Sep 1999 19:48:40 -0400
Message-ID: <13510.937007320@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I wrote:
This was in the process doing table creates/drops, and I surmise that
the problem was a tuple move executed concurrently by the process doing
VACUUM. In other words, it looks like this problem of missing lock
operations might be the cause, or one cause, of Michael's symptoms.
On looking closer, that's not so, because the particular path taken here
*does* have a lock --- DeleteAttributeTuples() acquires
AccessExclusiveLock on pg_attribute, which is the relation heap_delete
is failing to find a tuple in. The tuple it's trying to delete was
located by means of SearchSysCacheTupleCopy().
What I now think is that we have a variant of the SI-too-late problem:
vacuum has moved the underlying tuple, but the backend trying to do
the deletion hasn't heard about it yet, because it hasn't executed
a transaction start or CommandCounterIncrement since VACUUM processed
the table. This is bolstered by the postmaster log, which shows the
second backend dying just as VACUUM commits pg_attribute:
DEBUG: Rel pg_type: Pages: 6 --> 2; Tuple(s) moved: 1. Elapsed 0/0 sec.
DEBUG: Index pg_type_typname_index: Pages 5; Tuples 116: Deleted 1. Elapsed 0/0 sec.
DEBUG: Index pg_type_oid_index: Pages 2; Tuples 116: Deleted 1. Elapsed 0/0 sec.
DEBUG: --Relation pg_attribute--
DEBUG: Pages 33: Changed 1, Reapped 28, Empty 0, New 0; Tup 438: Vac 1976, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 97, MaxLen 97; Re-using: Free/Avail. Space 214444/207148; EndEmpty/Avail. Pages 0/27. Elapsed 0/0 sec.
DEBUG: Index pg_attribute_attrelid_index: Pages 15; Tuples 438: Deleted 1976. Elapsed 0/1 sec.
DEBUG: Index pg_attribute_relid_attnum_index: Pages 15; Tuples 438: Deleted 1976. Elapsed 0/0 sec.
DEBUG: Index pg_attribute_relid_attnam_index: Pages 48; Tuples 438: Deleted 1976. Elapsed 0/1 sec.
DEBUG: Rel pg_attribute: Pages: 33 --> 6; Tuple(s) moved: 8. Elapsed 0/0 sec.
DEBUG: Index pg_attribute_attrelid_index: Pages 15; Tuples 438: Deleted 8. Elapsed 0/0 sec.
DEBUG: Index pg_attribute_relid_attnum_index: Pages 15; Tuples 438: Deleted 8. Elapsed 0/0 sec.
DEBUG: Index pg_attribute_relid_attnam_index: Pages 48; Tuples 438: Deleted 8. Elapsed 0/0 sec.
TRAP: Failed Assertion("!(( lp)->lp_flags & 0x01):", File: "heapam.c", Line: 1121)
!(( lp)->lp_flags & 0x01) (0) [Not a typewriter]
DEBUG: --Relation pg_proc--
DEBUG: Pages 21: Changed 0, Reapped 0, Empty 0, New 0; Tup 1021: Vac 0, Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 145, MaxLen 197; Re-using: Free/Avail. Space 0/0; EndEmpty/Avail. Pages 0/0. Elapsed 0/0 sec.
(vacuum manages to get through a couple more tables before hearing the
"thou shalt exit" signal from the postmaster...)
It's looking to me like there may be no way to fix this in 6.5.*
short of adopting the recent 6.6 relcache/SI changes. Specifically,
the one we need is reading SI messages after acquiring a lock, but
I doubt we can pull out just that one without the rest.
I'm not real eager to do this given the little amount of testing
those changes have had, but maybe we have no choice...
regards, tom lane
From bouncefilter Fri Sep 10 20:32:31 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA54337
for <pgsql-hackers@postgresql.org>;
Fri, 10 Sep 1999 20:31:40 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id BAA18876
for pgsql-hackers@postgresql.org; Sat, 11 Sep 1999 01:35:13 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909110035.BAA18876@argh.demon.co.uk>
Subject: serial type
To: pgsql-hackers@postgresql.org
Date: Sat, 11 Sep 1999 01:35:13 +0100 (BST)
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Ummmm
Okee, this may be my setup being weird. I have been working on that
vacuum analyze bug and that may have killed something in the pg tables.
However, I am slightly concerned about this.
I am using 6.5.2 beta (the tarball on the ftp site)
-----------------------------
$ createdb games
% psql games
Welcome to the POSTGRESQL interactive sql monitor:
Please read the file COPYRIGHT for copyright terms of POSTGRESQL
[PostgreSQL 6.5.1 on i586-pc-linux-gnu, compiled by gcc -ggdb ]
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: games
games=> create table game (
games-> refnum serial
games-> );
NOTICE: CREATE TABLE will create implicit sequence 'game_refnum_seq' for SERIAL column 'game.refnum'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'game_refnum_key' for table 'game'
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally
before or while processing the request.
We have lost the connection to the backend, so further processing is impossible. Terminating.
--------------------------------------------
Having top running when I do this, the backend eats all of my
available memory in about 5 seconds, before crashing or just aborting
when it has no memory left to alloacte.
Now, I have realised a mistake I made. I set my postmaster to run at:
/usr/bin/postmaster -d 30 -S -N 128 -B 256 -D/var/lib/pgsql/data > /tmp/postmasterout 2> /tmp/postmastererr
I set the debug to be -30 instead of its maximum of -3
Oops, it works now, but surely setting the debug level too high by
accident shouldnt cause a loop that eats everything in sight?
I have tested this switching the debug value to be 30 or 3 and in all
instances the 30 crashes it and the 3 does not. I am just concerned
that this may be an indication of a real problem that may notjust be
something that happens when the commandline args are set wrongly.
Just something that might bear looking into
~Michael
From bouncefilter Sat Sep 11 04:07:42 1999
Received: from ext04.sra.co.jp (IDENT:root@ykh28DS01.kng.mesh.ad.jp
[133.205.214.1]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA88725
for <pgsql-hackers@postgreSQL.org>;
Sat, 11 Sep 1999 04:07:34 -0400 (EDT)
(envelope-from t-ishii@ext04.sra.co.jp)
Received: from ext04.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext04.sra.co.jp (8.8.8/8.8.8) with ESMTP id RAA06269
for <pgsql-hackers@postgreSQL.org>; Sat, 11 Sep 1999 17:01:27 +0900
Message-Id: <199909110801.RAA06269@ext04.sra.co.jp>
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: pgsql-hackers@postgreSQL.org
Subject: case bug?
Date: Sat, 11 Sep 1999 17:01:27 +0900
Sender: t-ishii@ext04.sra.co.jp
Following case statement is legal but fails in 6.5.1.
drop table t1;
DROP
create table t1(i int);
CREATE
insert into t1 values(-1);
INSERT 4047465 1
insert into t1 values(0);
INSERT 4047466 1
insert into t1 values(1);
INSERT 4047467 1
select i,
case
when i < 0 then 'minus'
when i = 0 then 'zero'
when i > 0 then 'plus'
else null
end
from t1;
ERROR: Unable to locate type oid 0 in catalog
note that:
select i,
case
when i < 0 then 'minus'
when i = 0 then 'zero'
when i > 0 then 'plus'
end
from t1;
also causes the same error.
---
Tatsuo Ishii
From bouncefilter Sat Sep 11 09:42:40 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 JAA01391
for <pgsql-hackers@postgreSQL.org>;
Sat, 11 Sep 1999 09:42:37 -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 NAA17622;
Sat, 11 Sep 1999 13:41:59 GMT
Sender: lockhart@hub.org
Message-ID: <37DA5C27.53887306@alumni.caltech.edu>
Date: Sat, 11 Sep 1999 13:41:59 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] case bug?
References: <199909110801.RAA06269@ext04.sra.co.jp>
Content-Type: multipart/mixed; boundary="------------BDBB901D733FEEA4DA09F279"
This is a multi-part message in MIME format.
--------------BDBB901D733FEEA4DA09F279
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Following case statement is legal but fails in 6.5.1.
select i,
case
when i < 0 then 'minus'
when i = 0 then 'zero'
when i > 0 then 'plus'
else null
end
from t1;
ERROR: Unable to locate type oid 0 in catalog
Hmm. Works OK when *any* of the result values have a type associated
with them, and has trouble when they are all of unspecified type,
which afaik can only happen with strings. Patch enclosed; I haven't
tested much but it *should* be very safe; I had protected against this
case elsewhere in the same routine.
(different test values, but same schema)
Original code:
select i,
case
when i < 0 then 'minus'
when i = 0 then 'zero'
when i > 0 then 'plus'::text
else null
end
from t1;
i|case
-+----
1|plus
2|plus
3|plus
(3 rows)
After patching:
select i,
case
when i < 0 then 'minus'
when i = 0 then 'zero'
when i > 0 then 'plus'
else null
end
from t1;
i|case
-+----
1|plus
2|plus
3|plus
(3 rows)
Can you please exercise it and let me know if you are happy? After
that I'll commit to CURRENT and RELEASE trees...
Oh, I've found another case which has trouble, and have not yet fixed
it:
insert into t2(i)
select case when i > 0 then '0' else null end from t1;
INSERT 0 3
postgres=> select * from t2;
i| x
---------+---
137173488|
137173488|
137173488|
It's never doing a conversion at all, and is putting (probably) the
pointer to the character string into the int4 result :(
Works OK when the string type is coerced:
insert into t2(i)
select case when i > 0 then '0'::int4 else null end from t1;
postgres=> select * from t2;
i| x
---------+---
0|
0|
0|
- Tom
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
--------------BDBB901D733FEEA4DA09F279
Content-Type: text/plain; charset=us-ascii;
name="parse_expr.c.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="parse_expr.c.patch"
*** parse_expr.c.orig Sat Sep 11 13:27:11 1999
--- parse_expr.c Sat Sep 11 13:24:03 1999
***************
*** 410,416 ****
* only bother with conversion if not NULL and
* different type...
*/
! if (wtype && (wtype != ptype))
{
if (can_coerce_type(1, &wtype, &ptype))
{
--- 410,417 ----
* only bother with conversion if not NULL and
* different type...
*/
! if (wtype && (wtype != UNKNOWNOID)
! && (wtype != ptype))
{
if (can_coerce_type(1, &wtype, &ptype))
{--------------BDBB901D733FEEA4DA09F279--
From bouncefilter Sat Sep 11 11:35:42 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA04545
for <pgsql-hackers@postgresql.org>;
Sat, 11 Sep 1999 11:35:28 -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 LAA14731;
Sat, 11 Sep 1999 11:34:29 -0400 (EDT)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] case bug?
In-reply-to: Your message of Sat, 11 Sep 1999 17:01:27 +0900
<199909110801.RAA06269@ext04.sra.co.jp>
Date: Sat, 11 Sep 1999 11:34:28 -0400
Message-ID: <14729.937064068@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
Following case statement is legal but fails in 6.5.1.
select i,
case
when i < 0 then 'minus'
when i = 0 then 'zero'
when i > 0 then 'plus'
else null
end
from t1;
ERROR: Unable to locate type oid 0 in catalog
Still there in current sources, too. Looks like it's the "else null"
that triggers the problem --- probably the code that is resolving the
final output type of the CASE expression isn't coping with a null.
I think this is Lockhart's turf, but I can have a go at it if he hasn't
got time to work on it...
regards, tom lane
From bouncefilter Sat Sep 11 11:56:48 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 LAA05465
for <pgsql-hackers@postgreSQL.org>;
Sat, 11 Sep 1999 11:56:46 -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 LAA14865;
Sat, 11 Sep 1999 11:56:09 -0400 (EDT)
To: Michael Simms <grim@argh.demon.co.uk>
cc: pgsql-hackers@postgreSQL.org,
Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] serial type
In-reply-to: Your message of Sat, 11 Sep 1999 01:35:13 +0100 (BST)
<199909110035.BAA18876@argh.demon.co.uk>
Date: Sat, 11 Sep 1999 11:56:09 -0400
Message-ID: <14863.937065369@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Simms <grim@argh.demon.co.uk> writes:
games=> create table game (
games-> refnum serial
games-> );
NOTICE: CREATE TABLE will create implicit sequence 'game_refnum_seq' for SERIAL column 'game.refnum'
NOTICE: CREATE TABLE/UNIQUE will create implicit index 'game_refnum_key' for table 'game'
pqReadData() -- backend closed the channel unexpectedly.
I set the debug to be -30 instead of its maximum of -3
Actually, 3 is not the maximum: 4 and 5 turn on dumping of parse and
plan trees.
What I find is that the parsetree dump attempt recurses infinitely,
because the parser is producing a parsetree with circular references.
The ColumnDef node for refnum has a list of constraints, and one of the
constraints is a CONSTR_UNIQUE node that has a keys list that points
right back at that same ColumnDef node. Try to dump it, and presto:
infinite recursion in the node print functions.
I am not sure if this is a mistake in the construction of the parsetree
(Thomas, what do you think?) or if the node print functions need to be
modified. I think it'd be easiest to alter the parsetree, though.
Perhaps the UNIQUE constraint ought to be attached somewhere else.
regards, tom lane
From bouncefilter Sat Sep 11 13:59:14 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA09216
for <pgsql-hackers@postgreSQL.org>;
Sat, 11 Sep 1999 13:58:19 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id NAA15136;
Sat, 11 Sep 1999 13:57:46 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org, "Michael Simms" <grim@argh.demon.co.uk>
Subject: Fixing Simms' vacuum problems
Date: Sat, 11 Sep 1999 13:57:46 -0400
Message-ID: <15133.937072666@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Michael Simms was kind enough to give me login privileges on his system
to poke at his problems with vacuum running concurrently with table
create/drop operations. I am not sure why his setup seems to display
the problem easier than mine does, but it's certainly true that crashes
occur very easily there, whereas it often takes many tries for me.
Anyway, I am now convinced that his symptoms are indeed explained by the
locking and cache-invalidation problems we have been discussing. I saw
a number of different failures, but they all seemed to trace back to one
of two common themes:
(1) The non-vacuuming backend crashes because of accessing a
system-relation tuple that isn't in the same place anymore: the tuple
is found in the local syscache, but the item location recorded there is
stale because vacuum has moved the tuple, and the non-vacuum process
hasn't noticed the SI update message for it yet.
(2) The vacuuming backend can fail because of trying to vacuum a
relation that's already been deleted. This can be blamed on the known
bug that DROP TABLE releases its exclusive lock on the target table
before end of transaction.
I expect there are also failures due to the lack-of-lock problems that
Hiroshi recently identified, but I didn't happen to see any of those in
the limited number of cases that I watched with the debugger.
So, it looks like a solution involves two components: first, being more
careful to lock system relations appropriately, and second, being sure
that SI messages are seen soon enough. I think the read-SI-messages-
at-lock-time code that's already in place for 6.6 will be sufficient for
the second point, if we are religious about acquiring appropriate locks.
(BTW, I think that in most cases an appropriate lock on a system table
will be less strong than AccessExclusiveLock --- Vadim, do you agree?)
Once we have the changes, the next question is do we want to risk
back-patching them into 6.5.2? I can see several ways that we could
proceed:
1. Back-patch into REL6_5, and postpone 6.5.2 release for a while
for beta-testing.
2. Put out 6.5.2 now (since it already has several other useful fixes),
then back-patch, and release 6.5.3 after a beta-testing interval.
3. Leave these changes out of 6.5.*, and try to get 6.6 out the door
soon instead.
I am not eager to hurry 6.6 along --- I have a lot of half-done work
in the planner/optimizer that I'd like to finish for 6.6. Perhaps
choice #2 is the way to go. Comments?
regards, tom lane
From bouncefilter Sat Sep 11 15:04:15 1999
Received: from argh.demon.co.uk (IDENT:grim@argh.demon.co.uk [193.237.6.55])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA11203
for <pgsql-hackers@postgresql.org>;
Sat, 11 Sep 1999 15:03:15 -0400 (EDT)
(envelope-from grim@argh.demon.co.uk)
Received: (from grim@localhost) by argh.demon.co.uk (8.9.3/8.9.3) id TAA20818
for pgsql-hackers@postgresql.org; Sat, 11 Sep 1999 19:39:38 +0100
From: Michael Simms <grim@argh.demon.co.uk>
Message-Id: <199909111839.TAA20818@argh.demon.co.uk>
Subject: Re: Fixing Simms' vacuum problems
To: pgsql-hackers@postgresql.org
Date: Sat, 11 Sep 1999 19:39:38 +0100 (BST)
In-Reply-To: <15133.937072666@sss.pgh.pa.us> from "Tom Lane" at Sep 11,
1999 01:57:46 PM
X-Mailer: ELM [version 2.5 PL0pre8]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Once we have the changes, the next question is do we want to risk
back-patching them into 6.5.2? I can see several ways that we could
proceed:
1. Back-patch into REL6_5, and postpone 6.5.2 release for a while
for beta-testing.
2. Put out 6.5.2 now (since it already has several other useful fixes),
then back-patch, and release 6.5.3 after a beta-testing interval.
3. Leave these changes out of 6.5.*, and try to get 6.6 out the door
soon instead.I am not eager to hurry 6.6 along --- I have a lot of half-done work
in the planner/optimizer that I'd like to finish for 6.6. Perhaps
choice #2 is the way to go. Comments?regards, tom lane
I woudl also suggest number 2 would be best for all. It means teh bugfix for
my (and potentially other peoples) problems gets fixed before 6.6 but there
is no delay to the 6.5.2 bugfixes being released.
I am curious, is there a reason that there is not a regular release of the
development tree also? I am aware we can get it through CVS to hammer
on it, but releases would be easier in many ways, certainly easier to develop
patches against.
Just a thought, as it seems that the linux kernel benefits greatly from
this approach.
As a final word, I would like to thank tom for his looking into
the problem. I have been really impressed with the responses
of the postgresql developers, they seem to be a lot more approachable and
willing to fix problems than in most other open source systems I have
seen.
Hopefully when I get a bit more time and get more familiar with the
postgresql code, I'll be able to actually provide some solutions
instead of just breaking it and telling you lot {:-)
Thanks!
~Michael
From bouncefilter Sat Sep 11 18:51:18 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 SAA17502
for <pgsql-hackers@postgreSQL.org>;
Sat, 11 Sep 1999 18:50:52 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA24262
for <pgsql-hackers@postgreSQL.org>;
Sat, 11 Sep 1999 18:50:16 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Status report: long-query-string changes
Date: Sat, 11 Sep 1999 18:50:16 -0400
Message-ID: <24259.937090216@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
I have finished applying Mike Ansley's changes for long queries, along
with a bunch of my own. The current status is:
* You can send a query string of indefinite length to the backend.
(This is poorly tested for MULTIBYTE, though; would someone who
uses MULTIBYTE more than I do try it out?)
* You can get back an EXPLAIN or error message string of indefinite
length.
* Single lexical tokens within a query are currently limited to 64k
because of the lexer's use of YY_REJECT. I have not committed any
of Leon's proposed lexer changes, since that issue still seems
controversial. I would like to see us agree on a solution.
(ecpg's lexer has the same problem, of course.)
Although I think the backend is in fairly good shape, there are still
a few minor trouble spots. (The rule deparser will blow up at 8K for
example --- I have some work to do in there and will fix it when
I get a chance.)
In the frontend libraries and clients, both libpq and psql are length-
limit-free. I have not looked much at any of the other frontend
interface libraries. I suspect that at least odbc and the python
interface need work, because quick glimpse searches show suspicious-
looking constants:
MAX_QUERY_SIZE
ERROR_MSG_LENGTH
SQL_PACKET_SIZE
MAX_MESSAGE_LEN
TEXT_FIELD_SIZE
MAX_VARCHAR_SIZE
DRV_VARCHAR_SIZE
DRV_LONGVARCHAR_SIZE
MAX_BUFFER_SIZE
MAX_FIELDS
The real problem in the clients is that pg_dump blithely assumes it
will never need to deal with strings over MAX_QUERY_SIZE. This is
a bad idea --- it ought to be rewritten to use the expansible-string-
buffer facility that now exists in libpq. There may be restrictions
in the other programs in bin/ as well, though glimpse didn't turn up
any red flags.
I would like to encourage the odbc and python folks to get rid of the
length limitations in their modules; I don't use either and have no
intention of touching either. I'd like to find a volunteer other than
myself to fix pg_dump, too.
Now, all we need is someone to implement multiple-disk-block tuples ;-)
regards, tom lane
From bouncefilter Sat Sep 11 19:26:18 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 TAA18414
for <pgsql-hackers@postgreSQL.org>;
Sat, 11 Sep 1999 19:26:05 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U113.dialup.udm.net [192.168.53.113])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id EAA88156;
Sun, 12 Sep 1999 04:23:50 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37DAE419.91AC6332@udmnet.ru>
Date: Sun, 12 Sep 1999 04:22:01 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
References: <24259.937090216@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
* Single lexical tokens within a query are currently limited to 64k
because of the lexer's use of YY_REJECT. I have not committed any
of Leon's proposed lexer changes, since that issue still seems
controversial. I would like to see us agree on a solution.
Thomas Lockhart should speak up - he seems the only person who
has objections yet. If the proposed thing is to be declined, something
has to be applied instead in respect to lexer reject feature and
accompanying size limits, as well as grammar inconsistency. Seems there
are only awkward solutions as alternatives. As you probably remember,
the proposed change only breaks constructs like 1+-2, which anyone
in a sane condition should avoid when programming :)
There are more size restrictions there. I noticed (by simply eyeing the
lexer source, without testing) that in case of flex lexer
(FLEX_LEXER being defined in scan.c) lexer can't
swallow big queries. You (Tom and Michael) aren't using flex,
are you?
--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.
From bouncefilter Sat Sep 11 20:40:19 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA20119
for <pgsql-hackers@postgreSQL.org>;
Sat, 11 Sep 1999 20:39: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 UAA00802;
Sat, 11 Sep 1999 20:38:22 -0400 (EDT)
To: Leon <leon@udmnet.ru>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
In-reply-to: Your message of Sun, 12 Sep 1999 04:22:01 +0500
<37DAE419.91AC6332@udmnet.ru>
Date: Sat, 11 Sep 1999 20:38:21 -0400
Message-ID: <800.937096701@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Leon <leon@udmnet.ru> writes:
There are more size restrictions there. I noticed (by simply eyeing the
lexer source, without testing) that in case of flex lexer
(FLEX_LEXER being defined in scan.c) lexer can't
swallow big queries. You (Tom and Michael) aren't using flex,
are you?
Huh? flex is the only lexer that works with the Postgres .l files,
as far as I know. Certainly it's what I'm using.
If you're looking at the "literal" buffer, that would need to be made
expansible, but there's not much point until flex's internal stuff is
fixed.
regards, tom lane
From bouncefilter Sun Sep 12 18:05:34 1999
Received: from ext04.sra.co.jp (IDENT:root@ykh28DS04.kng.mesh.ad.jp
[133.205.214.4]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA22478
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 18:05:04 -0400 (EDT)
(envelope-from t-ishii@ext04.sra.co.jp)
Received: from ext04.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id JAA01118;
Sun, 12 Sep 1999 09:56:58 +0900
Message-Id: <199909120056.JAA01118@ext16.sra.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org, "Michael Simms" <grim@argh.demon.co.uk>
Subject: Re: [HACKERS] Fixing Simms' vacuum problems
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Sat, 11 Sep 1999 13:57:46 -0400.
<15133.937072666@sss.pgh.pa.us>
Date: Sun, 12 Sep 1999 09:56:58 +0900
Sender: t-ishii@ext04.sra.co.jp
Once we have the changes, the next question is do we want to risk
back-patching them into 6.5.2? I can see several ways that we could
proceed:
1. Back-patch into REL6_5, and postpone 6.5.2 release for a while
for beta-testing.
2. Put out 6.5.2 now (since it already has several other useful fixes),
then back-patch, and release 6.5.3 after a beta-testing interval.
3. Leave these changes out of 6.5.*, and try to get 6.6 out the door
soon instead.I am not eager to hurry 6.6 along --- I have a lot of half-done work
in the planner/optimizer that I'd like to finish for 6.6. Perhaps
choice #2 is the way to go. Comments?
Seems #2 is good choice for me too.
---
Tatsuo Ishii
From bouncefilter Sat Sep 11 21:04:19 1999
Received: from ext16.sra.co.jp (IDENT:root@ykh28DS16.kng.mesh.ad.jp
[133.205.214.16]) by hub.org (8.9.3/8.9.3) with ESMTP id VAA20960
for <pgsql-hackers@postgreSQL.org>;
Sat, 11 Sep 1999 21:03:18 -0400 (EDT)
(envelope-from t-ishii@ext04.sra.co.jp)
Received: from ext04.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id JAA01126;
Sun, 12 Sep 1999 09:57:04 +0900
Message-Id: <199909120057.JAA01126@ext16.sra.co.jp>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] case bug?
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Sat, 11 Sep 1999 13:41:59 GMT.
<37DA5C27.53887306@alumni.caltech.edu>
Date: Sun, 12 Sep 1999 09:57:04 +0900
Sender: t-ishii@ext04.sra.co.jp
Thomas,
Can you please exercise it and let me know if you are happy? After
that I'll commit to CURRENT and RELEASE trees...
Looks ok for me. Thanks.
---
Tatsuo Ishii
From bouncefilter Sun Sep 12 18:05:33 1999
Received: from ext04.sra.co.jp (IDENT:root@ykh28DS04.kng.mesh.ad.jp
[133.205.214.4]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA22257
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 18:04:57 -0400 (EDT)
(envelope-from t-ishii@ext04.sra.co.jp)
Received: from ext04.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id KAA01146;
Sun, 12 Sep 1999 10:00:46 +0900
Message-Id: <199909120100.KAA01146@ext16.sra.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Sat, 11 Sep 1999 18:50:16 -0400.
<24259.937090216@sss.pgh.pa.us>
Date: Sun, 12 Sep 1999 10:00:46 +0900
Sender: t-ishii@ext04.sra.co.jp
I have finished applying Mike Ansley's changes for long queries, along
with a bunch of my own. The current status is:* You can send a query string of indefinite length to the backend.
(This is poorly tested for MULTIBYTE, though; would someone who
uses MULTIBYTE more than I do try it out?)
I'll take care of this.
---
Tatsuo Ishii
From bouncefilter Sun Sep 12 05:17:25 1999
Received: from mail.lhsystems.hu (IDENT:mail@charon.lhsystems.hu
[195.56.119.2]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA52850
for <pgsql-hackers@postgresql.org>;
Sun, 12 Sep 1999 05:17:10 -0400 (EDT)
(envelope-from gabriel@lhsystems.hu)
Received: (from mail@localhost) by mail.lhsystems.hu (8.8.7/8.8.7) id KAA01334
for <pgsql-hackers@postgresql.org>; Sun, 12 Sep 1999 10:18:11 +0200
X-Authentication-Warning: charon.lhsystems.hu: mail set sender to
<gabriel@lhsystems.hu> using -f
Received: from garfield.lhsystems.hu(160.10.3.6) by charon.lhsystems.hu via
smap (V2.1) id xma001332; Sun, 12 Sep 99 10:18:00 +0200
Received: from localhost (gabriel@localhost)
by lhsystems.hu (8.9.1/8.9.1) with SMTP id KAA25844
for <pgsql-hackers@postgresql.org>; Sun, 12 Sep 1999 10:09:25 +0200
Date: Sun, 12 Sep 1999 10:09:25 +0200 (MET DST)
From: Gabriel Akos <gabriel@lhsystems.hu>
To: pgsql-hackers@postgresql.org
Subject: Possible bug...
Message-ID: <Pine.LNX.4.02.9909121004010.25555-100000@garfield.lhsystems.hu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
Sorry for the intrusion, but the www-based bug tracking seems to be down
(URL not found by the www server).
My problem: I'm testing 6.5.1 on a Linux (old RedHat 4.2,libc5) box.
I did the regression tests, and int2 ant int4 failed, but int8 was ok.
But this is the minor problem, maybe my Linux is outdated...
The other problem, this seems to be a real one:
1. I create a table with a primary key
2. With ALTER TABLE RENAME I change the name of the table...
3. The name of the primary key index does not follow the table...
4. When I try to remove the index, no success, even renaming the table
back does not help (is not possible)
Best regards,
--
GA'BRIEL, A'kos (Akos.Gabriel@lhsystems.hu)
Forte system administrator of Lufthansa Systems Hungary
Forte and UNIX consultant
Phone: (+36-1) 4312-979 FAX: (+36-1) 4312-977
PS: I'll try to install Postgres on a Sun Ultra Enterprise 2*300MHz,
1GB RAM machine... If anyone interested, I may supply test results :)
From bouncefilter Sun Sep 12 04:58:25 1999
Received: from smtp2.free.fr (root@smtp2.free.fr [212.27.32.6])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA50357;
Sun, 12 Sep 1999 04:58:10 -0400 (EDT)
(envelope-from renato.barrios@online.fr)
Received: from online.fr (toulouse-63-80.dial.proxad.net [212.27.63.80])
by smtp2.free.fr (8.9.3/8.9.3/Debian/GNU) with ESMTP id KAA03338;
Sun, 12 Sep 1999 10:57:53 +0200
Sender: renato@smtp2.free.fr
Message-ID: <37DB86C8.F1A43E3D@online.fr>
Date: Sun, 12 Sep 1999 10:56:09 +0000
From: renato barrios <renato.barrios@online.fr>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.0.34 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Dmitry Samersoff <dms@wplus.net>, pg-general@postgresql.org,
Postgres Hackers List <hackers@postgresql.org>,
Oleg Broytman <phd@emerald.netskate.ru>
Subject: Re: [HACKERS] Re: Query about postgres medical database
References: <XFMail.990910192155.dms@wplus.net>
Content-Type: multipart/alternative;
boundary="------------113352E053B54501DFA125C5"
--------------113352E053B54501DFA125C5
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Dmitry Samersoff wrote:
On 10-Sep-99 Thomas Lockhart wrote:
I am physician and I am very interested by possibilities postgresql
could offer to medical information management, specially in undeveloped
countries.
In the userguide you speake about a medical database and I would want to
contact people responsable of this project.I believe that this example was from the days when Postgres was
developing at Berkeley. I know that there are more recent projects
(one of our contributors is an administrator at a hospital) and the
best way to find out about current projects is to post a question to a
mailing list.Does anyone have something going in the medical info area?
I was the maintainer/developer of postgresql based project for
City's Health department of St. Petersburg (RUSSIA),
This project includes financial part (medical insurance reports) and
numerouse statistical reports
(sex/age/diagnozis corellation, loads of different clinics and so on)This project starts 1995 and it's succesfuly working now but without me ...
---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...
and >Oleg Broytman <phd@emerald.netskate.ru>
Hello!
I work for Russian National Research Surgery Centre (www.med.ru). I have
a database of patient data on Novel server, and I am writing and debugging
programs to store the data in Postgres. The dedicated host is oper.med.ru.
But I do not see anything special about the data - for me it is just
data that can be stored, searched and retrieved.
Hello!
Thank you for your messages, I am trying to organize a group in medical info
area.
It would be a very important database sub-group with postgresql ad open code
source.
I think data is specially interesting in this area. It is not only about
decisions to use integers or floats in the results of tests. It could be the
case to go and work with the definition of this types (Actually only simple
mathematical relations like grams by liter for tests, and so on ). I will not
write nothing about other areas where storing objects would be of interest (
medical imagery or treatement of biological signals... )
But finishing with science fiction, a medical database could be proposed like
an exemple of code source for the postgresql_doc mantainers, like in the case
of the V C++ GUI framework documentation by Bruce Wampler of the
ftp://www.objectcentral.com/wvrefman.121.tar.gz. and be of greate utility for
end users.
It would have a conceptualisation model ( I think like in the v case with
Coad-Yourdon notation ) and all the code of the database.
If it would be possible to start with the database, it would be easier to add
extensions adapted for users.
...and...and...
I am not...not... a hacker but I have a lot...lot... of information about the
medical subject.
Thanks,
Renato
--------------113352E053B54501DFA125C5
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Dmitry Samersoff wrote:
<blockquote TYPE=CITE>On 10-Sep-99 Thomas Lockhart wrote:
<br>>> I am physician and I am very interested by possibilities postgresql
<br>>> could offer to medical information management, specially in undeveloped
<br>>> countries.
<br>>> In the userguide you speake about a medical database and I would
want to
<br>>> contact people responsable of this project.
<br>>
<br>> I believe that this example was from the days when Postgres was
<br>> developing at Berkeley. I know that there are more recent projects
<br>> (one of our contributors is an administrator at a hospital) and the
<br>> best way to find out about current projects is to post a question
to a
<br>> mailing list.
<br>>
<br>> Does anyone have something going in the medical info area?
<p>I was the maintainer/developer of postgresql based project for
<br>City's Health department of St. Petersburg (RUSSIA),
<br>This project includes financial part (medical insurance reports) and
<br>numerouse statistical reports
<br>(sex/age/diagnozis corellation, loads of different clinics and so on)
<p>This project starts 1995 and it's succesfuly working now but without
me ...
<p>---
<br>Dmitry Samersoff, dms@wplus.net, ICQ:3161705
<br><a href="http://devnull.wplus.net">http://devnull.wplus.net</a>
<br>* There will come soft rains ...</blockquote>
and >Oleg Broytman <phd@emerald.netskate.ru>
<br>>Hello!
<p>> I work for Russian National Research Surgery Centre (www.med.ru).
I have
<br>>a database of patient data on Novel server, and I am writing and debugging
<br>>programs to store the data in Postgres. The dedicated host is oper.med.ru.
<br>> But I do not see anything special about the data - for me it
is just
<br>>data that can be stored, searched and retrieved.
<p>Hello!
<br>Thank you for your messages, I am trying to organize a group in medical
info area.
<br>It would be a very important database sub-group with postgresql ad
open code source.
<br>I think data is specially interesting in this area. It is not
only about decisions to use integers or floats in the results of tests. It
could be the case to go and work with the definition of this types (Actually
only simple mathematical relations like grams by liter for tests, and so
on ). I will not write nothing about other areas where storing objects
would be of interest ( medical imagery or treatement of biological
signals... )
<p>But finishing with science fiction, a medical database could be proposed
like an exemple of code source for the postgresql_doc mantainers, like
in the case of the V C++ GUI framework documentation by Bruce Wampler
of the <a href="ftp://www.objectcentral.com/wvrefman.121.tar.gz">ftp://www.objectcentral.com/wvrefman.121.tar.gz.
</a>and be of greate utility for end users.
<br>It would have a conceptualisation model ( I think like in the v case
with Coad-Yourdon notation ) and all the code of the database.
<br>If it would be possible to start with the database, it would be easier
to add extensions adapted for users.
<br>...and...and...<br>
I am not...not... a hacker but I have a lot...lot... of information about
the medical subject.<br>
Thanks,
<br>Renato
</body>
</html>
--------------113352E053B54501DFA125C5--
From bouncefilter Sun Sep 12 08:23:27 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 IAA62550
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 08:23:01 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (A129.dialup.udm.net [213.24.0.129])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id RAA85925;
Sun, 12 Sep 1999 17:20:56 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37DB9892.2711763E@udmnet.ru>
Date: Sun, 12 Sep 1999 17:12:02 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
References: <800.937096701@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
If you're looking at the "literal" buffer, that would need to be made
expansible, but there's not much point until flex's internal stuff is
fixed.
Look at this piece of code. It seems that when myinput() had been called
once, for the second time it will return 0 even if string isn't
over yet. Parameter 'max' is 8192 bytes on my system. So the query is
simply truncated to that size.
#ifdef FLEX_SCANNER
/* input routine for flex to read input from a string instead of a file */
static int
myinput(char* buf, int max)
{
int len, copylen;
if (parseCh == NULL)
{
len = strlen(parseString);
if (len >= max)
copylen = max - 1;
else
copylen = len;
if (copylen > 0)
memcpy(buf, parseString, copylen);
buf[copylen] = '\0';
parseCh = parseString;
return copylen;
}
else
return 0; /* end of string */
}
#endif /* FLEX_SCANNER */
--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.
From bouncefilter Sun Sep 12 11:36:29 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA73797
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 11:35:39 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA02382;
Sun, 12 Sep 1999 11:34:32 -0400 (EDT)
To: Leon <leon@udmnet.ru>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
In-reply-to: Your message of Sun, 12 Sep 1999 17:12:02 +0500
<37DB9892.2711763E@udmnet.ru>
Date: Sun, 12 Sep 1999 11:34:32 -0400
Message-ID: <2380.937150472@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Leon <leon@udmnet.ru> writes:
Look at this piece of code. It seems that when myinput() had been called
once, for the second time it will return 0 even if string isn't
over yet.
It's always a good idea to pull a fresh copy of the sources
before opinionating about what works or doesn't work in someone's
just-committed changes ;-)
regards, tom lane
From bouncefilter Sun Sep 12 12:09:30 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 MAA79141
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 12:09:17 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA02615;
Sun, 12 Sep 1999 12:08:39 -0400 (EDT)
To: Gabriel Akos <gabriel@lhsystems.hu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Possible bug...
In-reply-to: Your message of Sun, 12 Sep 1999 10:09:25 +0200 (MET DST)
<Pine.LNX.4.02.9909121004010.25555-100000@garfield.lhsystems.hu>
Date: Sun, 12 Sep 1999 12:08:39 -0400
Message-ID: <2613.937152519@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Gabriel Akos <gabriel@lhsystems.hu> writes:
I did the regression tests, and int2 ant int4 failed, but int8 was ok.
They're probably OK, just platform-specific variations in error message
wording. Did you examine regression.diffs?
1. I create a table with a primary key
2. With ALTER TABLE RENAME I change the name of the table...
3. The name of the primary key index does not follow the table...
It wouldn't, and doesn't need to.
4. When I try to remove the index, no success, even renaming the table
back does not help (is not possible)
ALTER TABLE RENAME is pretty broken, I think --- in current sources it
fails even worse than above. (Looks like it needs to flush dirty
buffers for the rel before changing the name of the underlying Unix
files --- else mdblindwrt fails later on.) You might find that killing
and restarting the postmaster will bring things back to a consistent
state.
In general, Postgres' support for ALTER TABLE is very weak; there are
a lot of cases that aren't handled correctly. Perhaps someone will
step up to the plate and improve it someday.
regards, tom lane
From bouncefilter Sun Sep 12 16:47:33 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 QAA03740
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 16:47:01 -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 RAA97067;
Sun, 12 Sep 1999 17:46:55 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 12 Sep 1999 17:46:54 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org, Michael Simms <grim@argh.demon.co.uk>
Subject: Re: [HACKERS] Fixing Simms' vacuum problems
In-Reply-To: <15133.937072666@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9909121745070.54336-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 11 Sep 1999, Tom Lane wrote:
Once we have the changes, the next question is do we want to risk
back-patching them into 6.5.2? I can see several ways that we could
proceed:
1. Back-patch into REL6_5, and postpone 6.5.2 release for a while
for beta-testing.
2. Put out 6.5.2 now (since it already has several other useful fixes),
then back-patch, and release 6.5.3 after a beta-testing interval.
3. Leave these changes out of 6.5.*, and try to get 6.6 out the door
soon instead.I am not eager to hurry 6.6 along --- I have a lot of half-done work
in the planner/optimizer that I'd like to finish for 6.6. Perhaps
choice #2 is the way to go. Comments?
Option 2 makes *me* feel the most comfortable...we were holding off on
6.5.2 due to some things ppl were working on...are those complete? I can
roll out a 6.5.2 tonight if everyone feel comfortable with it, or wait for
a few days (Wednesday?) to make sure all is iron'd out?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Sep 12 16:48:33 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 QAA03791
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 16:47:40 -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 RAA97071;
Sun, 12 Sep 1999 17:47:50 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 12 Sep 1999 17:47:50 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Michael Simms <grim@argh.demon.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Fixing Simms' vacuum problems
In-Reply-To: <199909111839.TAA20818@argh.demon.co.uk>
Message-ID: <Pine.BSF.4.10.9909121747100.54336-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 11 Sep 1999, Michael Simms wrote:
I am curious, is there a reason that there is not a regular release of the
development tree also? I am aware we can get it through CVS to hammer
on it, but releases would be easier in many ways, certainly easier to develop
patches against.
ftp://ftp.postgresql.org/pub/postgresql-snapshot.tar.gz
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Sep 12 18:39:34 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 SAA26127
for <pgsql-hackers@postgresql.org>;
Sun, 12 Sep 1999 18:39:27 -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 TAA99270
for <pgsql-hackers@postgresql.org>;
Sun, 12 Sep 1999 19:39:42 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 12 Sep 1999 19:39:41 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgresql.org
Subject: configure & template files ...
Message-ID: <Pine.BSF.4.10.9909121933480.54336-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Before I dive into this, has anyone else noticed that the SRCH_INC and
SRCH_LIB options in the templates no longer work?
To test, I modified template/freebsd as follows:
AROPT:cq
SHARED_LIB:-fpic -DPIC
CFLAGS:-O2 -m486 -pipe
SRCH_INC:/usr/local/include
SRCH_LIB:
USE_LOCALE:no
DLSUFFIX:.so
YFLAGS:-d
YACC:bison -y
Adding /usr/local/include to SRCH_INC, but when I run configure, it
reports:
- setting CPPFLAGS=
- setting LDFLAGS=
I'm suspecting this code in configure.in:
[
rm -f conftest.sh
sed 's/^\([A-Za-z_]*\):\(.*\)$/\1="\2"/' "template/$TEMPLATE" >conftest.sh
. ./conftest.sh
rm -f conftest.sh
]
Isn't working as expected...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Sep 12 18:51:34 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 SAA27818
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 18:50:43 -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 TAA01111
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 19:50:58 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 12 Sep 1999 19:50:57 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] configure & template files ...
In-Reply-To: <Pine.BSF.4.10.9909121933480.54336-100000@thelab.hub.org>
Message-ID: <Pine.BSF.4.10.9909121950280.54336-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Found and fixed...we checked for INCLUDE_DIR being defined, but not
SRCH_INC...same for libs...
On Sun, 12 Sep 1999, The Hermit Hacker wrote:
Before I dive into this, has anyone else noticed that the SRCH_INC and
SRCH_LIB options in the templates no longer work?To test, I modified template/freebsd as follows:
AROPT:cq
SHARED_LIB:-fpic -DPIC
CFLAGS:-O2 -m486 -pipe
SRCH_INC:/usr/local/include
SRCH_LIB:
USE_LOCALE:no
DLSUFFIX:.so
YFLAGS:-d
YACC:bison -yAdding /usr/local/include to SRCH_INC, but when I run configure, it
reports:- setting CPPFLAGS=
- setting LDFLAGS=I'm suspecting this code in configure.in:
[
rm -f conftest.sh
sed 's/^\([A-Za-z_]*\):\(.*\)$/\1="\2"/' "template/$TEMPLATE" >conftest.sh
. ./conftest.sh
rm -f conftest.sh
]Isn't working as expected...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Sep 12 19:34: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 TAA32776
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 19:33: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 TAA05761;
Sun, 12 Sep 1999 19:32:48 -0400 (EDT)
To: The Hermit Hacker <scrappy@hub.org>
cc: pgsql-hackers@postgreSQL.org, Michael Simms <grim@argh.demon.co.uk>
Subject: Re: [HACKERS] Fixing Simms' vacuum problems
In-reply-to: Your message of Sun, 12 Sep 1999 17:46:54 -0300 (ADT)
<Pine.BSF.4.10.9909121745070.54336-100000@thelab.hub.org>
Date: Sun, 12 Sep 1999 19:32:48 -0400
Message-ID: <5759.937179168@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
The Hermit Hacker <scrappy@hub.org> writes:
Option 2 makes *me* feel the most comfortable...we were holding off on
6.5.2 due to some things ppl were working on...are those complete? I can
roll out a 6.5.2 tonight if everyone feel comfortable with it, or wait for
a few days (Wednesday?) to make sure all is iron'd out?
I don't have any more code changes that I want to try to squeeze into
6.5.2, but I thought Bruce still needed to update the change log etc
etc. Dunno about the rest of the crew; anyone have more to do?
regards, tom lane
From bouncefilter Sun Sep 12 20:09:08 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA37763
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 20:08:25 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id UAA06786;
Sun, 12 Sep 1999 20:06:41 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909130006.UAA06786@candle.pha.pa.us>
Subject: Re: [HACKERS] Fixing Simms' vacuum problems
In-Reply-To: <5759.937179168@sss.pgh.pa.us> from Tom Lane at "Sep 12,
1999 07:32:48 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 12 Sep 1999 20:06:41 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org,
Michael Simms <grim@argh.demon.co.uk>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
The Hermit Hacker <scrappy@hub.org> writes:
Option 2 makes *me* feel the most comfortable...we were holding off on
6.5.2 due to some things ppl were working on...are those complete? I can
roll out a 6.5.2 tonight if everyone feel comfortable with it, or wait for
a few days (Wednesday?) to make sure all is iron'd out?I don't have any more code changes that I want to try to squeeze into
6.5.2, but I thought Bruce still needed to update the change log etc
etc. Dunno about the rest of the crew; anyone have more to do?
Yes, I have to do that.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Sep 12 20:29:08 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA41252
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 20:29:01 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id UAA08380;
Sun, 12 Sep 1999 20:28:51 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909130028.UAA08380@candle.pha.pa.us>
Subject: pgaccess update for 6.5.2?
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Sun, 12 Sep 1999 20:28:51 -0400 (EDT)
CC: teo@flex.ro
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Do people want pgaccess updated to 0.98 for the 6.5.2 release?
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Sep 12 21:19:14 1999
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA47763
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 21:19:00 -0400 (EDT)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m11QKlk-000LECC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgreSQL.org; Sun, 12 Sep 1999 20:18:56 -0500 (CDT)
Date: Sun, 12 Sep 1999 20:18:56 -0500
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: pgsql-hackers@postgreSQL.org
Subject: pg_dump table order
Message-ID: <19990912201856.A20044@wallace.ece.rice.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
Hey hackers:
I'vebeen using pg_dump in a typical three db setup: development,
staging, and live. The output of pg_dump is ordered by oid, so as the
db's histories diverge, the output does as well. That is, if identical
tables get created in the development and staging dbs, for example, but
in a different order, I can't us diff to test this. I was wondering if
there is any reason why the order couldn't be by tablename, instead of
oid, since the ordering of creation of sequences and types and such is
taken care of.
Ah I think I just figured it out: it's that pesky object
support, isn't it? In order to use a table (class) as a member (field)
of another table, it has to exist first, and the only thing in the
system table that ensures that is oid. Bummer. Hmm, it'd still be useful
for comparision purposes, but it wouldn't gaurantee correct SQL scripts.
Perhaps I'll just hack my local copy with an extra switch for "class
name order output". Anyone else want it?
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
From bouncefilter Sun Sep 12 21:36:09 1999
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA50200
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 21:35:28 -0400 (EDT)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m11QL1j-000LECC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgreSQL.org; Sun, 12 Sep 1999 20:35:27 -0500 (CDT)
Date: Sun, 12 Sep 1999 20:35:27 -0500
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump table order
Message-ID: <19990912203527.B20044@wallace.ece.rice.edu>
References: <19990912201856.A20044@wallace.ece.rice.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
In-Reply-To: <19990912201856.A20044@wallace.ece.rice.edu>;
from Ross J. Reedstrom on Sun, Sep 12, 1999 at 08:18:56PM -0500
On Sun, Sep 12, 1999 at 08:18:56PM -0500, Ross J. Reedstrom wrote:
Ah I think I just figured it out: it's that pesky object
support, isn't it? In order to use a table (class) as a member (field)
of another table, it has to exist first, and the only thing in the
system table that ensures that is oid. Bummer. Hmm, it'd still be useful
Talking to myself: "Gee Ross, why don't you read the friendly comments
in the source you just found the ordey by oid in, explaining exactly
this point?"
Ross "the blind"
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
From bouncefilter Sun Sep 12 22:06:09 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA53731
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 22:05:52 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id WAA09513;
Sun, 12 Sep 1999 22:05:35 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909130205.WAA09513@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dump table order
In-Reply-To: <19990912201856.A20044@wallace.ece.rice.edu> from "Ross J.
Reedstrom" at "Sep 12, 1999 08:18:56 pm"
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Date: Sun, 12 Sep 1999 22:05:35 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Hey hackers:
I'vebeen using pg_dump in a typical three db setup: development,
staging, and live. The output of pg_dump is ordered by oid, so as the
db's histories diverge, the output does as well. That is, if identical
tables get created in the development and staging dbs, for example, but
in a different order, I can't us diff to test this. I was wondering if
there is any reason why the order couldn't be by tablename, instead of
oid, since the ordering of creation of sequences and types and such is
taken care of.Ah I think I just figured it out: it's that pesky object
support, isn't it? In order to use a table (class) as a member (field)
of another table, it has to exist first, and the only thing in the
system table that ensures that is oid. Bummer. Hmm, it'd still be useful
for comparision purposes, but it wouldn't gaurantee correct SQL scripts.
Perhaps I'll just hack my local copy with an extra switch for "class
name order output". Anyone else want it?
I thought someone already did that. It may be in 6.5.1.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Sep 12 22:48:10 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA58343
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 22:48:07 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id WAA10070;
Sun, 12 Sep 1999 22:47:47 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909130247.WAA10070@candle.pha.pa.us>
Subject: Re: [HACKERS] Fixing Simms' vacuum problems]
In-Reply-To: <5759.937179168@sss.pgh.pa.us> from Tom Lane at "Sep 12,
1999 07:32:48 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sun, 12 Sep 1999 22:47:47 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org,
"Michael Simms"@candle.pha.pa.us, grim@argh.demon.co.uk,
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
The Hermit Hacker <scrappy@hub.org> writes:
Option 2 makes *me* feel the most comfortable...we were holding off on
6.5.2 due to some things ppl were working on...are those complete? I can
roll out a 6.5.2 tonight if everyone feel comfortable with it, or wait for
a few days (Wednesday?) to make sure all is iron'd out?I don't have any more code changes that I want to try to squeeze into
6.5.2, but I thought Bruce still needed to update the change log etc
etc. Dunno about the rest of the crew; anyone have more to do?
I have updated everything needed for 6.5.2. Thomas, can you update the
HISTORY file for 6.5.2. Thanks.
This is good timing. I just finished a 4-month project yesterday.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Sun Sep 12 22:55:10 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 WAA59052
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 22:54:46 -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 XAA02415;
Sun, 12 Sep 1999 23:54:41 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Sun, 12 Sep 1999 23:54:41 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org,
"Michael Simms"@candle.pha.pa.us, grim@argh.demon.co.uk,
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Subject: Re: [HACKERS] Fixing Simms' vacuum problems]
In-Reply-To: <199909130247.WAA10070@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909122354120.412-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 12 Sep 1999, Bruce Momjian wrote:
The Hermit Hacker <scrappy@hub.org> writes:
Option 2 makes *me* feel the most comfortable...we were holding off on
6.5.2 due to some things ppl were working on...are those complete? I can
roll out a 6.5.2 tonight if everyone feel comfortable with it, or wait for
a few days (Wednesday?) to make sure all is iron'd out?I don't have any more code changes that I want to try to squeeze into
6.5.2, but I thought Bruce still needed to update the change log etc
etc. Dunno about the rest of the crew; anyone have more to do?I have updated everything needed for 6.5.2. Thomas, can you update the
HISTORY file for 6.5.2. Thanks.
Okay, will wrap 6.5.2 on Tuesday evening then...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Sun Sep 12 23:34:11 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 XAA65729
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 23:33:57 -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 DAA20159;
Mon, 13 Sep 1999 03:33:08 GMT
Sender: lockhart@hub.org
Message-ID: <37DC7074.1C1ACAA1@alumni.caltech.edu>
Date: Mon, 13 Sep 1999 03:33:08 +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: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
References: <24259.937090216@sss.pgh.pa.us> <37DAE419.91AC6332@udmnet.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart should speak up - he seems the only person who
has objections yet. If the proposed thing is to be declined, something
has to be applied instead in respect to lexer reject feature and
accompanying size limits, as well as grammar inconsistency.
Hmm. I'd suggest that we go with the "greedy lexer" solution, which
continues to gobble characters which *could* be an operator until
other characters or whitespace are encountered.
I don't recall any compelling cases for which this would be an
inadequate solution, and we have plenty of time until v6.6 is released
to discover problems and work out alternatives.
Sorry for slowing things up; but fwiw I *did* think about it some more
;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Sun Sep 12 23:46:16 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 XAA68153
for <pgsql-hackers@postgreSQL.org>;
Sun, 12 Sep 1999 23:46:11 -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 DAA20176;
Mon, 13 Sep 1999 03:45:28 GMT
Sender: lockhart@hub.org
Message-ID: <37DC7358.AE1E6DAB@alumni.caltech.edu>
Date: Mon, 13 Sep 1999 03:45:28 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Leon <leon@udmnet.ru>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
References: <24259.937090216@sss.pgh.pa.us> <37DAE419.91AC6332@udmnet.ru>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart should speak up...
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.
You talkin' to me?? ;)
So, while you are on the lexer warpath, I'd be really happy if someone
would fix the following behavior:
(I'm doing this from memory, but afaik it is close to correct)
For non-psql applications, such as tcl or ecpg, which do not do any
pre-processing on input tokens, a trailing un-terminated string will
be lost, and no error will be detected. For example,
select * from t1 'abc
sent directly to the server will not fail as it should with that
garbage at the end. The lexer is in a non-standard mode after all
tokens are processed, and the accumulated string "abc" is left in a
buffer and not sent to yacc/bison. I think you can see this behavior
just by looking at the lexer code.
A simple fix would be to check the current size after lexing of that
accumulated string buffer, and if it is non-zero then elog(ERROR) a
complaint. Perhaps a more general fix would be to ensure that you are
never in an exclusive state after all tokens are processed, but I'm
not sure how to do that.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Sep 13 00:06:11 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 AAA75814
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 00:06:06 -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 EAA20476;
Mon, 13 Sep 1999 04:05:28 GMT
Sender: lockhart@hub.org
Message-ID: <37DC7808.27C76C50@alumni.caltech.edu>
Date: Mon, 13 Sep 1999 04:05:28 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: The Hermit Hacker <scrappy@hub.org>, pgsql-hackers@postgreSQL.org,
Michael Simms <grim@argh.demon.co.uk>
Subject: Re: [HACKERS] Fixing Simms' vacuum problems
References: <5759.937179168@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I don't have any more code changes that I want to try to squeeze into
6.5.2, but I thought Bruce still needed to update the change log etc
etc. Dunno about the rest of the crew; anyone have more to do?
I should put in my recent fix for Tatsuo regarding unspecified string
types in case statements. Should get to it this evening (Monday
morning, GMT)...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Sep 13 00:32:11 1999
Received: from idiom.com ([209.157.64.1])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA80233
for <pgsql-hackers@hub.org>; Mon, 13 Sep 1999 00:31:31 -0400 (EDT)
(envelope-from jason@idiom.com)
Received: from idiom.com (jason@localhost [127.0.0.1])
by idiom.com (8.9.3/8.9.3) with ESMTP id VAA44038
for <pgsql-hackers@hub.org>; Sun, 12 Sep 1999 21:30:50 -0700 (PDT)
Message-Id: <199909130430.VAA44038@idiom.com>
To: pgsql-hackers@hub.org
Subject: jdbc1 large objects and 651 -- does it work for anyone
Date: Sun, 12 Sep 1999 21:30:49 -0700
From: Jason Venner <jason@idiom.com>
Calling setBytes or any attempt to do LargeObject.write(byte[])
returns
[on the java side]
Oid gotten from lom.create() is 641377
FastPath call returned ERROR: lo_write: invalid large obj descriptor (0)
at postgresql.fastpath.Fastpath.fastpath(Fastpath.java:141)
at postgresql.fastpath.Fastpath.fastpath(Fastpath.java:188)
at postgresql.largeobject.LargeObject.write(LargeObject.java:173)
at RestoreBlobs.main(RestoreBlobs.java:298)
The -d3 log of the postmaster has
nitPostgres
StartTransactionCommand
query: set datestyle to 'ISO'
ProcessUtility: set datestyle to 'ISO'
CommitTransactionCommand
StartTransactionCommand
query: select proname, oid from pg_proc where proname = 'lo_open' or proname = 'lo_close' or proname = 'lo_creat' or proname = 'lo_unl\
ink' or proname = 'lo_lseek' or proname = 'lo_tell' or proname = 'loread' or proname = 'lowrite'
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
ERROR: lo_write: invalid large obj descriptor (0)
AbortCurrentTransaction
pq_recvbuf: unexpected EOF on client connection
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
pq_recvbuf: unexpected EOF on client connection
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
pq_recvbuf: unexpected EOF on client connection
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
From bouncefilter Mon Sep 13 02:10:13 1999
Received: from flex.flex.ro (IDENT:root@[193.230.255.4])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA91502
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 02:09:54 -0400 (EDT) (envelope-from teo@flex.ro)
Received: from flex.ro (IDENT:teo@teo.flex.ro [193.230.255.3])
by flex.flex.ro (8.9.3/8.9.3) with ESMTP id JAA27316;
Mon, 13 Sep 1999 09:10:31 +0300
Sender: teo@flex.flex.ro
Message-ID: <37DC96C8.4847B264@flex.ro>
Date: Mon, 13 Sep 1999 06:16:40 +0000
From: Constantin Teodorescu <teo@flex.ro>
Organization: FLEX Consulting Braila
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: pgaccess update for 6.5.2?
References: <199909130028.UAA08380@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Do people want pgaccess updated to 0.98 for the 6.5.2 release?
It would be just fine.
I'm waiting for a german translation this week and everything seems to
be ok. No bugs have been discovered.
When should be the package prepared to be inserted into 6.5.2 ?
--
Constantin Teodorescu
FLEX Consulting Braila, ROMANIA
From bouncefilter Mon Sep 13 02:41:13 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 CAA05115
for <pgsql-hackers@hub.org>; Mon, 13 Sep 1999 02:41:10 -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 finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1)
id 11QPnY-000NML-0C; Mon, 13 Sep 1999 06:41:09 +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 GAA19222; Mon, 13 Sep 1999 06:40:32 GMT
Received: by exchange1.nt.maidstone.gov.uk with Internet Mail Service
(5.5.1960.3) id <S428RMWV>; Mon, 13 Sep 1999 07:39:06 +0100
Message-ID:
<1B3D5E532D18D311861A00600865478C25E5B9@exchange1.nt.maidstone.gov.uk>
From: Peter Mount <petermount@it.maidstone.gov.uk>
To: "'Jason Venner'" <jason@idiom.com>, pgsql-hackers@hub.org
Subject: RE: [HACKERS] jdbc1 large objects and 651 -- does it work for any one
Date: Mon, 13 Sep 1999 07:39:01 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
This looks like you have either not got AutoCommit set to false, or are
calling commit() between calls. As of 6.5.x LargeObjects need to be
wrapped within a transaction, but if I'm right, all open LO's are closed
on commit().
Peter
--
Peter Mount
Enterprise Support
Maidstone Borough Council
Any views stated are my own, and not those of Maidstone Borough Council.
-----Original Message-----
From: Jason Venner [mailto:jason@idiom.com]
Sent: 13 September 1999 05:31
To: pgsql-hackers@hub.org
Subject: [HACKERS] jdbc1 large objects and 651 -- does it work for
anyone
Calling setBytes or any attempt to do LargeObject.write(byte[])
returns
[on the java side]
Oid gotten from lom.create() is 641377
FastPath call returned ERROR: lo_write: invalid large obj descriptor
(0)
at postgresql.fastpath.Fastpath.fastpath(Fastpath.java:141)
at postgresql.fastpath.Fastpath.fastpath(Fastpath.java:188)
at
postgresql.largeobject.LargeObject.write(LargeObject.java:173)
at RestoreBlobs.main(RestoreBlobs.java:298)
The -d3 log of the postmaster has
nitPostgres
StartTransactionCommand
query: set datestyle to 'ISO'
ProcessUtility: set datestyle to 'ISO'
CommitTransactionCommand
StartTransactionCommand
query: select proname, oid from pg_proc where proname = 'lo_open' or
proname = 'lo_close' or proname = 'lo_creat' or proname = 'lo_unl\
ink' or proname = 'lo_lseek' or proname = 'lo_tell' or proname =
'loread' or proname = 'lowrite'
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
ERROR: lo_write: invalid large obj descriptor (0)
AbortCurrentTransaction
pq_recvbuf: unexpected EOF on client connection
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
pq_recvbuf: unexpected EOF on client connection
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
pq_recvbuf: unexpected EOF on client connection
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
************
From bouncefilter Mon Sep 13 04:22:14 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA18325
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 04:21:31 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <S4RBA6FG>; Mon, 13 Sep 1999 10:21:48 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C062@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Thomas Lockhart'" <lockhart@alumni.caltech.edu>, Leon <leon@udmnet.ru>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Status report: long-query-string changes
Date: Mon, 13 Sep 1999 10:16:54 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
When is 6.6 being released? I'm not sure about the greedy lexer, I don't
really know enough to comment, but at first glance, yes fine. The question
is, though, what are possible operators. Do we limit the user-defined
operators in PG to only to a specific subset of characters. Perhaps we
should lex each operator separately, and then get the compiler to construct
logical operators from the physical components that it gets.
MikeA
-----Original Message-----
From: Thomas Lockhart [mailto:lockhart@alumni.caltech.edu]
Sent: Monday, September 13, 1999 5:33 AM
To: Leon
Cc: Tom Lane; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changesThomas Lockhart should speak up - he seems the only person who
has objections yet. If the proposed thing is to bedeclined, something
has to be applied instead in respect to lexer reject feature and
accompanying size limits, as well as grammar inconsistency.Hmm. I'd suggest that we go with the "greedy lexer" solution, which
continues to gobble characters which *could* be an operator until
other characters or whitespace are encountered.I don't recall any compelling cases for which this would be an
inadequate solution, and we have plenty of time until v6.6
is released
to discover problems and work out alternatives.Sorry for slowing things up; but fwiw I *did* think about it
some more
;)- Thomas
--
Thomas Lockhart
lockhart@alumni.caltech.edu
South Pasadena, California************
From bouncefilter Mon Sep 13 09:47:18 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 JAA57315
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 09:47:02 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U117.dialup.udm.net [192.168.53.117])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id SAA88780
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 18:47:31 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37DCFD80.2886C65F@udmnet.ru>
Date: Mon, 13 Sep 1999 18:34:56 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Status report: long-query-string changes
References: <24259.937090216@sss.pgh.pa.us> <37DAE419.91AC6332@udmnet.ru>
<37DC7074.1C1ACAA1@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Thomas Lockhart should speak up - he seems the only person who
has objections yet. If the proposed thing is to be declined, something
has to be applied instead in respect to lexer reject feature and
accompanying size limits, as well as grammar inconsistency.Hmm. I'd suggest that we go with the "greedy lexer" solution, which
continues to gobble characters which *could* be an operator until
other characters or whitespace are encountered.
'Xcuse my dumbness ;) , but is it in any way different from
what is proposed (by me and some others?)
--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.
From bouncefilter Mon Sep 13 09:47:23 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 JAA57314
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 09:47:00 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U117.dialup.udm.net [192.168.53.117])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id SAA88786
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 18:47:38 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37DCFD90.942065B4@udmnet.ru>
Date: Mon, 13 Sep 1999 18:35:12 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Status report: long-query-string changes
References: <24259.937090216@sss.pgh.pa.us> <37DAE419.91AC6332@udmnet.ru>
<37DC7358.AE1E6DAB@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Thomas Lockhart should speak up...
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.You talkin' to me?? ;)
Nein, nein! Sei still bitte! :) This is my signature which is a week
old already :)
A simple fix would be to check the current size after lexing of that
accumulated string buffer, and if it is non-zero then elog(ERROR) a
complaint. Perhaps a more general fix would be to ensure that you are
never in an exclusive state after all tokens are processed, but I'm
not sure how to do that.
The solution is obvious - to eliminate exclusive states entirely!
Banzai!!!
--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.
From bouncefilter Mon Sep 13 10:07:18 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 KAA60329
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 10:06:57 -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 LAA06543;
Mon, 13 Sep 1999 11:05:25 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 13 Sep 1999 11:05:25 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Constantin Teodorescu <teo@flex.ro>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: pgaccess update for 6.5.2?
In-Reply-To: <37DC96C8.4847B264@flex.ro>
Message-ID: <Pine.BSF.4.10.9909131104580.54336-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 13 Sep 1999, Constantin Teodorescu wrote:
Bruce Momjian wrote:
Do people want pgaccess updated to 0.98 for the 6.5.2 release?
It would be just fine.
I'm waiting for a german translation this week and everything seems to
be ok. No bugs have been discovered.
When should be the package prepared to be inserted into 6.5.2 ?
Am going to do a roll-out on Tuesday evenin...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Mon Sep 13 10:10:18 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 KAA60639
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 10:09:28 -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 KAA09475;
Mon, 13 Sep 1999 10:08:39 -0400 (EDT)
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
In-reply-to: Your message of Mon, 13 Sep 1999 10:16:54 +0200
<1BF7C7482189D211B03F00805F8527F748C062@S-NATH-EXCH2>
Date: Mon, 13 Sep 1999 10:08:39 -0400
Message-ID: <9473.937231719@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
When is 6.6 being released?
Schedule? You want a schedule???
Seriously, I'd have to guess at least three months off. Vadim wants to
do transaction logging, I've got a lot of half-baked optimizer work to
finish, and I dunno what anyone else has up their sleeve.
The goal used to be a major release every three months, but we haven't
met that in some time. And, since it seems like we are now putting
out major releases in order to do significant upgrades and not just
incremental stability improvements, I kinda think that a slower cycle
(six-month intervals, say) might be a more useful goal at this stage.
Has the core group thought about this issue lately?
regards, tom lane
From bouncefilter Mon Sep 13 16:48:46 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id QAA61235
for pgsql-hackers@postgresql.org; Mon, 13 Sep 1999 16:48:00 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: "John Henry" <troy@teenpornsluts.com>
X-Newsgroups: comp.databases.postgresql.hackers
Subject: - WANTED
Date: Tue, 14 Sep 1999 00:10:37 +1000
Lines: 8
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <37dd0560@news.ausmail.com>
X-Trace: 14 Sep 1999 00:08:32 +1000, 203.24.22.190
To: pgsql-hackers@postgresql.org
Hi im surfing the net to try and find someone who can help me. A friend of
mine told me that there are some people who know how to get sites listed at
the top of the search engines. I run an adult website am willing to pay
someone who can do this.
From bouncefilter Mon Sep 13 10:38:18 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 KAA08670
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 10:37:51 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U118.dialup.udm.net [192.168.53.118])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id TAA93527;
Mon, 13 Sep 1999 19:38:20 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37DD0B37.E8F8F931@udmnet.ru>
Date: Mon, 13 Sep 1999 19:33:27 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>,
hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Status report: long-query-string changes
References: <24259.937090216@sss.pgh.pa.us> <37DAE419.91AC6332@udmnet.ru>
<37DC7358.AE1E6DAB@alumni.caltech.edu>
<37DCF957.D1083FF1@udmnet.ru>
<37DD018E.9257428B@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
The solution is obvious - to eliminate exclusive states entirely!
Banzai!!!That will complicate the lexer, and make it more brittle and difficult
to read, since you will have to, essentially, implement the exclusive
states using flags within each element.If you want to try it as an exercise, we *might* find it isn't as ugly
as I am afraid it will be, but...
Gimme the latest lexer source. (I pay for my Internet on a per
minute basis, so I can't connect to CVS) You will see what I mean.
--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.
From bouncefilter Mon Sep 13 11:01:18 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA12186
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 11:00:49 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id KAA15983;
Mon, 13 Sep 1999 10:36:28 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909131436.KAA15983@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: pgaccess update for 6.5.2?
In-Reply-To: <37DC96C8.4847B264@flex.ro> from Constantin Teodorescu at "Sep
13,
1999 06:16:40 am"
To: Constantin Teodorescu <teo@flex.ro>
Date: Mon, 13 Sep 1999 10:36:28 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
Do people want pgaccess updated to 0.98 for the 6.5.2 release?
It would be just fine.
I'm waiting for a german translation this week and everything seems to
be ok. No bugs have been discovered.
When should be the package prepared to be inserted into 6.5.2 ?
The real issue was not if it was stable, but whether a non-bugfix
release of pgaccess was proper for a 6.5.2 release. I haven't heard any
comments on that yet. Not sure how I feel either.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 11:01:24 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA12264
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 11:01:20 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id KAA16087;
Mon, 13 Sep 1999 10:38:02 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909131438.KAA16087@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: pgaccess update for 6.5.2?
In-Reply-To: <Pine.BSF.4.10.9909131104580.54336-100000@thelab.hub.org> from
The
Hermit Hacker at "Sep 13, 1999 11:05:25 am"
To: The Hermit Hacker <scrappy@hub.org>
Date: Mon, 13 Sep 1999 10:38:02 -0400 (EDT)
CC: Constantin Teodorescu <teo@flex.ro>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Mon, 13 Sep 1999, Constantin Teodorescu wrote:
Bruce Momjian wrote:
Do people want pgaccess updated to 0.98 for the 6.5.2 release?
It would be just fine.
I'm waiting for a german translation this week and everything seems to
be ok. No bugs have been discovered.
When should be the package prepared to be inserted into 6.5.2 ?Am going to do a roll-out on Tuesday evenin...
I will take this as a "Yes", you want the new pgaccess. Adding it now.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 10:42:18 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 KAA09351
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 10:41: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 KAA09725;
Mon, 13 Sep 1999 10:41:04 -0400 (EDT)
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] pg_dump table order
In-reply-to: Your message of Sun, 12 Sep 1999 20:18:56 -0500
<19990912201856.A20044@wallace.ece.rice.edu>
Date: Mon, 13 Sep 1999 10:41:04 -0400
Message-ID: <9723.937233664@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu> writes:
Ah I think I just figured it out: it's that pesky object
support, isn't it? In order to use a table (class) as a member (field)
of another table, it has to exist first, and the only thing in the
system table that ensures that is oid. Bummer. Hmm, it'd still be useful
for comparision purposes, but it wouldn't gaurantee correct SQL scripts.
Perhaps I'll just hack my local copy with an extra switch for "class
name order output". Anyone else want it?
Better idea: make pg_dump smarter, so that it sorts the tables by name
as far as possible without breaking inheritance and membership
dependencies. It already retrieves the inheritance graph, and it could
certainly figure column-type dependencies too. I don't think anyone
would object to producing the output in a more meaningful order, so
I see no need for a switch if you can make this work.
I used to know enough about topological sorts to sketch how this ought
to work, but that was years ago :-(. I do see that the simplest
approach to a sort comparison function, "if a depends on b then say a>b,
else say result of comparing name(a) and name(b)", will not work because
it's not transitive.
regards, tom lane
From bouncefilter Mon Sep 13 10:45:19 1999
Received: from flex.flex.ro (IDENT:root@[193.230.255.4])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA09608
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 10:44:28 -0400 (EDT) (envelope-from teo@flex.ro)
Received: from flex.ro (IDENT:teo@teo.flex.ro [193.230.255.3])
by flex.flex.ro (8.9.3/8.9.3) with ESMTP id RAA11918;
Mon, 13 Sep 1999 17:45:06 +0300
Sender: teo@flex.flex.ro
Message-ID: <37DD0F64.4D0BF347@flex.ro>
Date: Mon, 13 Sep 1999 14:51:16 +0000
From: Constantin Teodorescu <teo@flex.ro>
Organization: FLEX Consulting Braila
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: pgaccess update for 6.5.2?
References: <199909131436.KAA15983@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
The real issue was not if it was stable, but whether a non-bugfix
release of pgaccess was proper for a 6.5.2 release. I haven't heard any
comments on that yet. Not sure how I feel either.
It's rock solid stable.
I am using it for 2 weeks and just minor bugs have been reported (some
color problems on Solaris that have been fixed, some messages missing
from translations).
It will be ready for tomorow to be picked up and included in 6.5.2
distribution.
Just I will need a final confirmation with 10 minutes before someone
downloads the .tar.gz to be sure that it will be the right one.
I'll be (I hope) reachable by e-mail checking my mailbox every 1 minute.
Please, there is available a bug fix list for 6.5.2 ?
Teo
From bouncefilter Mon Sep 13 10:55:18 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 KAA10971
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 10:54:27 -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 KAA09817;
Mon, 13 Sep 1999 10:53:20 -0400 (EDT)
To: Leon <leon@udmnet.ru>
cc: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Status report: long-query-string changes
In-reply-to: Your message of Mon, 13 Sep 1999 18:35:12 +0500
<37DCFD90.942065B4@udmnet.ru>
Date: Mon, 13 Sep 1999 10:53:19 -0400
Message-ID: <9815.937234399@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Leon <leon@udmnet.ru> writes:
A simple fix would be to check the current size after lexing of that
accumulated string buffer, and if it is non-zero then elog(ERROR) a
complaint. Perhaps a more general fix would be to ensure that you are
never in an exclusive state after all tokens are processed, but I'm
not sure how to do that.
The solution is obvious - to eliminate exclusive states entirely!
Banzai!!!
Can we do that? Seems like a more likely approach is to ensure that
all of the lexer states have rules that ensure they terminate (or
raise an error, as for unterminated quoted string) at end of input.
I do think checking the token buffer is a hack, and changing the rules
a cleaner solution...
regards, tom lane
From bouncefilter Mon Sep 13 11:33:49 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA17769
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 11:33:39 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA16778;
Mon, 13 Sep 1999 11:05:40 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909131505.LAA16778@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: pgaccess update for 6.5.2?
In-Reply-To: <37DD0F64.4D0BF347@flex.ro> from Constantin Teodorescu at "Sep
13,
1999 02:51:16 pm"
To: Constantin Teodorescu <teo@flex.ro>
Date: Mon, 13 Sep 1999 11:05:40 -0400 (EDT)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
The real issue was not if it was stable, but whether a non-bugfix
release of pgaccess was proper for a 6.5.2 release. I haven't heard any
comments on that yet. Not sure how I feel either.It's rock solid stable.
I am using it for 2 weeks and just minor bugs have been reported (some
color problems on Solaris that have been fixed, some messages missing
from translations).It will be ready for tomorow to be picked up and included in 6.5.2
distribution.
Just I will need a final confirmation with 10 minutes before someone
downloads the .tar.gz to be sure that it will be the right one.
I'll be (I hope) reachable by e-mail checking my mailbox every 1 minute.Please, there is available a bug fix list for 6.5.2 ?
Can I download it now?
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 11:20:43 1999
Received: from trends.net (root@clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA15615
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 11:20:41 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by trends.net (8.8.8/8.8.8) with ESMTP id LAA01804
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 11:20:34 -0400 (EDT)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <S4RBA60N>; Mon, 13 Sep 1999 17:20:45 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C071@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Tom Lane'" <tgl@sss.pgh.pa.us>, "Ansley, Michael"
<Michael.Ansley@intec.co.za>
Cc: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Status report: long-query-string changes
Date: Mon, 13 Sep 1999 17:15:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
Can I suggest that defined targets are set up for major releases (if they
aren't already). I don't think that major releases need to happen on a
regular cycle. That's for patch releases. Having three months or so's
worth of patches in a point release is useful, but I only want to upgrade
(as opposed to patch) a production environment when it's going to buy me a
well-defined set of new functions, e.g.: MVCC, unlimited row length, etc.,
etc. So if we don't have a major release for twelve or fourteen months, so
what. Besides, for anybody running a production environment, it could take
a couple of months worth of inhouse testing before they can make the move
anyway. When moving from Oracle 7.3 to 8.0, our system will go through 6-9
months worth of strenuous testing.
Are the releases currently time based, or function based, or a little bit of
both?
MikeA
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Monday, September 13, 1999 4:09 PM
To: Ansley, Michael
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes"Ansley, Michael" <Michael.Ansley@intec.co.za> writes:
When is 6.6 being released?
Schedule? You want a schedule???
Seriously, I'd have to guess at least three months off.
Vadim wants to
do transaction logging, I've got a lot of half-baked
optimizer work to
finish, and I dunno what anyone else has up their sleeve.The goal used to be a major release every three months, but
we haven't
met that in some time. And, since it seems like we are now putting
out major releases in order to do significant upgrades and not just
incremental stability improvements, I kinda think that a slower cycle
(six-month intervals, say) might be a more useful goal at this stage.
Has the core group thought about this issue lately?regards, tom lane
From bouncefilter Mon Sep 13 11:33:44 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA17679
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 11:32:54 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA16956;
Mon, 13 Sep 1999 11:16:25 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909131516.LAA16956@candle.pha.pa.us>
Subject: Re: [HACKERS] Status report: long-query-string changes
In-Reply-To: <9473.937231719@sss.pgh.pa.us> from Tom Lane at "Sep 13,
1999 10:08:39 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 13 Sep 1999 11:16:25 -0400 (EDT)
CC: "Ansley, Michael" <Michael.Ansley@intec.co.za>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
The goal used to be a major release every three months, but we haven't
met that in some time. And, since it seems like we are now putting
out major releases in order to do significant upgrades and not just
incremental stability improvements, I kinda think that a slower cycle
(six-month intervals, say) might be a more useful goal at this stage.
Has the core group thought about this issue lately?
I got a good laugh on this one. That we actually planned ahead... :-)
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 12:02:44 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA22238
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 12:02:17 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id LAA17272;
Mon, 13 Sep 1999 11:35:53 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909131535.LAA17272@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dump table order
In-Reply-To: <9723.937233664@sss.pgh.pa.us> from Tom Lane at "Sep 13,
1999 10:41:04 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 13 Sep 1999 11:35:53 -0400 (EDT)
CC: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Better idea: make pg_dump smarter, so that it sorts the tables by name
as far as possible without breaking inheritance and membership
dependencies. It already retrieves the inheritance graph, and it could
certainly figure column-type dependencies too. I don't think anyone
would object to producing the output in a more meaningful order, so
I see no need for a switch if you can make this work.I used to know enough about topological sorts to sketch how this ought
to work, but that was years ago :-(. I do see that the simplest
approach to a sort comparison function, "if a depends on b then say a>b,
else say result of comparing name(a) and name(b)", will not work because
it's not transitive.
I now someone fixed some of that recently, and I thought it was in 6.5.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 11:51:43 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA20661
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 11:51:12 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <S4RBA7AJ>; Mon, 13 Sep 1999 17:51:37 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C072@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Bruce Momjian'" <maillist@candle.pha.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Status report: long-query-string changes
Date: Mon, 13 Sep 1999 17:46:48 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
The goal used to be a major release every three months, but we haven't
met that in some time. And, since it seems like we are now putting
out major releases in order to do significant upgrades and not just
incremental stability improvements, I kinda think that a slower cycle
(six-month intervals, say) might be a more useful goal at this stage.
Has the core group thought about this issue lately?I got a good laugh on this one. That we actually planned ahead... :-)
Maybe the core team should take a look at the TODO list, and split it over
the next couple of release cycles. Then you can just say, when a and b and
c have been achieved, and are stable, then we release 6.x
This doesn't include bugs. Bugs must still be fixed and release in the
point releases, which should be every, say, three months.
As new stuff gets added to the TODO list (not bugs), it gets shuffled into
the release cycle. This isn't hard to manage once the first one has been
done, and you make a policy of only planning four or so releases ahead.
Then ou can post this plan on the web site, so that people know what stuff
is being worked on. Of course, CVS management becomes an issue, because if
someone feels like working on something that is not due for two releases,
does it go into the current source tree? If necessary, you can open up
branches for each planned release, and people can check out whichever one
they feel like working on. Of course, merging bug fixes becomes more of an
issue. Actually the more I think about it, the more complex it becomes, but
if the CVS management is not really an issue, then this is a possible
approach. Otherwise, we'll have to think of something else.
Of course, the core team are responsible for merging changes into the CVS
tree, so they could just implement a policy of only adding new functionality
that is required for the current release.
If somebody desperately wants something added, and can convince the core
team to include it in the current release cycle, then the code can be added
immediately (assuming that somebody has actually done). Alternatively, they
manage their own source tree, until such time as the code gets included.
MikeA
From bouncefilter Mon Sep 13 11:54:43 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 LAA20915
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 11:54:09 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA21734;
Mon, 13 Sep 1999 15:50:03 GMT
Sender: lockhart@hub.org
Message-ID: <37DD1D2B.F4929265@alumni.caltech.edu>
Date: Mon, 13 Sep 1999 15:50:03 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
CC: "'Tom Lane'" <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
References: <1BF7C7482189D211B03F00805F8527F748C071@S-NATH-EXCH2>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Are the releases currently time based, or function based,
or a little bit of both?
A bit of both. No new functionality would imply no new full release,
but that hasn't been a problem for the last three years ;)
imho, Tom Lane's query optimizer project and my in-progress join
syntax work would be enough to justify a new release after a couple
more months (we try to have a one month beta cycle to squash bugs and
to ensure testing across platforms). Of course, there are and will be
other new features and internal changes at least as large as the two I
mentioned which could justify the next release also.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Sep 13 12:33:43 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA26072
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 12:33:03 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id MAA19046;
Mon, 13 Sep 1999 12:30:58 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909131630.MAA19046@candle.pha.pa.us>
Subject: Re: [HACKERS] Status report: long-query-string changes
In-Reply-To: <1BF7C7482189D211B03F00805F8527F748C072@S-NATH-EXCH2> from
"Ansley, Michael" at "Sep 13, 1999 05:46:48 pm"
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
Date: Mon, 13 Sep 1999 12:30:58 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset iso-8859-1 unsupported, filtering to ASCII...]
The goal used to be a major release every three months, but we haven't
met that in some time. And, since it seems like we are now putting
out major releases in order to do significant upgrades and not just
incremental stability improvements, I kinda think that a slower cycle
(six-month intervals, say) might be a more useful goal at this stage.
Has the core group thought about this issue lately?I got a good laugh on this one. That we actually planned ahead... :-)
Maybe the core team should take a look at the TODO list, and split it over
the next couple of release cycles. Then you can just say, when a and b and
c have been achieved, and are stable, then we release 6.x
I would be nice if we could do that, but people work as they have time
and interest in certain areas. Also, things get fixed as people find
problems and we become more capable with the source code.
Hard to plan any of that.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 12:43: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 MAA27268
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 12:43:34 -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 UAA24463;
Mon, 13 Sep 1999 20:38:30 +0400 (MSD)
Date: Mon, 13 Sep 1999 20:38:30 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: HISTORY for 6.5.2
In-Reply-To: <199909131505.LAA16778@candle.pha.pa.us>
Message-ID: <Pine.GSO.3.96.SK.990913203428.425E-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Bruce,
in HISTORY for 6.5.2 I see:
This is to re-use space on index pages freed by vacuum(Tom)
isn't this re-use indices after vacuum hack by Vadim ?
(prevent indices to grow infinitely)
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From bouncefilter Mon Sep 13 13:12:45 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA30698
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 13:12:32 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id NAA22947;
Mon, 13 Sep 1999 13:11:11 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909131711.NAA22947@candle.pha.pa.us>
Subject: Re: HISTORY for 6.5.2
In-Reply-To: <Pine.GSO.3.96.SK.990913203428.425E-100000@ra> from Oleg Bartunov
at "Sep 13, 1999 08:38:30 pm"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Mon, 13 Sep 1999 13:11:11 -0400 (EDT)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce,
in HISTORY for 6.5.2 I see:
This is to re-use space on index pages freed by vacuum(Tom)
isn't this re-use indices after vacuum hack by Vadim ?
(prevent indices to grow infinitely)
Thanks. I have updated the release.sgml and the HISTORY file.
I should have posted the list of changes. Here it is. Gee, it is quite
a lot. Thomas, any way to get the dates from the release.sgml into the
HISTORY file and the html output?
---------------------------------------------------------------------------
Detailed Change List
subselect+CASE fixes(Tom)
Add SHLIB_LINK setting for solaris_i386 and solaris_sparc ports(Daren
Sefcik)
Fixes for CASE in WHERE join clauses(Tom)
Fix BTScan abort(Tom)
Repair the check for redundant UNIQUE and PRIMARY KEY indices(Tom)
Improve it so that it checks for multi-column constraints(Tom)
Fix for Win32 making problem with MB enabled(Hiroki Kataoka)
Allow BSD yacc and bison to compile pl code(Bruce)
Fix SET NAMES
int8 fixes(Thomas)
Fix vacuum's memory consumption(Tom)
Reduce the total memory consumption of vacuum(Tom)
Fix for timestamp(datetime)
Rule deparsing bugfixes(Tom)
Fix quoting problems in mkMakefile.tcldefs.sh.in and
mkMakefile.tkdefs.sh.in(Tom)
Update frontend libpq to remove limits on query lengths,
error/notice message lengths, and number of fields per tuple(Tom)
This is to re-use space on index pages freed by vacuum(Vadim)
document -x for pg_dump(Bruce)
Fix for unary operators in rule deparser(Tom)
Comment out FileUnlink of excess segments during mdtruncate()(Tom)
Irix linking fix from Yu Cao <yucao@falcon.kla-tencor.com>
Repair logic error in LIKE: should not return LIKE_ABORT
when reach end of pattern before end of text(Tom)
Repair incorrect cleanup of heap memory allocation during transaction
abort(Tom)
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 13:32:44 1999
Received: from ritchie.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA32996
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 13:31:49 -0400 (EDT)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by ritchie.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id VAA09777;
Mon, 13 Sep 1999 21:31:36 +0400 (MSK/MSD)
X-Real-To: tgl@sss.pgh.pa.us
Received: (from dms@localhost)
by woland.wplus.net (8.9.2/8.9.1/wplus.2) id VAA18176;
Mon, 13 Sep 1999 21:31:36 +0400 (MSD)
Message-ID: <XFMail.990913213135.dms@wplus.net>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199909131535.LAA17272@candle.pha.pa.us>
Date: Mon, 13 Sep 1999 21:31:35 +0400 (MSD)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dump table order
Cc: pgsql-hackers@postgreSQL.org,
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
Tom Lane <tgl@sss.pgh.pa.us>
On 13-Sep-99 Bruce Momjian wrote:
Better idea: make pg_dump smarter, so that it sorts the tables by name
as far as possible without breaking inheritance and membership
dependencies. It already retrieves the inheritance graph, and it could
certainly figure column-type dependencies too. I don't think anyone
would object to producing the output in a more meaningful order, so
I see no need for a switch if you can make this work.I used to know enough about topological sorts to sketch how this ought
to work, but that was years ago :-(. I do see that the simplest
approach to a sort comparison function, "if a depends on b then say a>b,
else say result of comparing name(a) and name(b)", will not work because
it's not transitive.I now someone fixed some of that recently, and I thought it was in 6.5.
Unfortunately not, if I use some functions in CONSTRANE clause of
CREATE TABLE, I can't restore from backup made by pg_dump.
It's nice idea always dump functions first.
---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...
From bouncefilter Mon Sep 13 13:39: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 NAA33729
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 13:39: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 NAA10356;
Mon, 13 Sep 1999 13:36:07 -0400 (EDT)
To: Oleg Bartunov <oleg@sai.msu.su>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] HISTORY for 6.5.2
In-reply-to: Your message of Mon, 13 Sep 1999 20:38:30 +0400 (MSD)
<Pine.GSO.3.96.SK.990913203428.425E-100000@ra>
Date: Mon, 13 Sep 1999 13:36:07 -0400
Message-ID: <10354.937244167@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Oleg Bartunov <oleg@sai.msu.su> writes:
in HISTORY for 6.5.2 I see:
This is to re-use space on index pages freed by vacuum(Tom)
isn't this re-use indices after vacuum hack by Vadim ?
Not mine, for sure.
regards, tom lane
From bouncefilter Mon Sep 13 13:43:44 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA34372
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 13:43:15 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id NAA02891;
Mon, 13 Sep 1999 13:42:24 -0400
Message-ID: <37DD3778.A42D51C3@wgcr.org>
Date: Mon, 13 Sep 1999 13:42:16 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Oleg Bartunov <oleg@sai.msu.su>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <199909131711.NAA22947@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
---------------------------------------------------------------------------
Detailed Change List
[snip]
Hey, Bruce -- did the patches for Alpha get in?? If not, I'll need to
mung Ryan K's/Uncle G's patchset against 6.5.1 to work with 6.5.2.
Your friendly RPM packager...
Lamar Owen
WGCR Internet Radio
From bouncefilter Mon Sep 13 13:43:44 1999
Received: from ritchie.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA34374
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 13:43:16 -0400 (EDT)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by ritchie.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id VAA11719
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 21:43:14 +0400 (MSK/MSD)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: (from dms@localhost)
by woland.wplus.net (8.9.2/8.9.1/wplus.2) id VAA18201
for pgsql-hackers@postgreSQL.org; Mon, 13 Sep 1999 21:43:14 +0400 (MSD)
Message-ID: <XFMail.990913214314.dms@wplus.net>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Mon, 13 Sep 1999 21:43:14 +0400 (MSD)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: pgsql-hackers@postgreSQL.org
Subject: Nested transactions
How about nesetd or/and named transactions?
Is it in plans for nearest future?
---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...
From bouncefilter Mon Sep 13 13:58:44 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA36468
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 13:57:38 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id NAA23374;
Mon, 13 Sep 1999 13:47:20 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909131747.NAA23374@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <37DD3778.A42D51C3@wgcr.org> from Lamar Owen at "Sep 13,
1999 01:42:16 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Mon, 13 Sep 1999 13:47:19 -0400 (EDT)
CC: Oleg Bartunov <oleg@sai.msu.su>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
---------------------------------------------------------------------------
Detailed Change List
[snip]
Hey, Bruce -- did the patches for Alpha get in?? If not, I'll need to
mung Ryan K's/Uncle G's patchset against 6.5.1 to work with 6.5.2.Your friendly RPM packager...
The bad news is that those patches are too large/significant for a minor
release. They could affect other platforms adversely, so we can't apply
them until 6.6.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 13:54:44 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA36022
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 13:54:38 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id NAA02916;
Mon, 13 Sep 1999 13:50:39 -0400
Message-ID: <37DD3969.BEEE3FEC@wgcr.org>
Date: Mon, 13 Sep 1999 13:50:33 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Oleg Bartunov <oleg@sai.msu.su>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
References: <199909131747.NAA23374@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
The bad news is that those patches are too large/significant for a minor
release. They could affect other platforms adversely, so we can't apply
them until 6.6.
Ok, mung time, then. That means RedHat will be releasing 6.5.1 with
RedHat 6.1, unless those patches can be munged relatively easily. Alpha
is a big platform for RedHat.
Lamar Owen
WGCR Internet Radio
From bouncefilter Mon Sep 13 13:57:44 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA36442
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 13:57:09 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id NAA23592;
Mon, 13 Sep 1999 13:55:09 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909131755.NAA23592@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <37DD3969.BEEE3FEC@wgcr.org> from Lamar Owen at "Sep 13,
1999 01:50:33 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Mon, 13 Sep 1999 13:55:09 -0400 (EDT)
CC: Oleg Bartunov <oleg@sai.msu.su>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian wrote:
The bad news is that those patches are too large/significant for a minor
release. They could affect other platforms adversely, so we can't apply
them until 6.6.Ok, mung time, then. That means RedHat will be releasing 6.5.1 with
RedHat 6.1, unless those patches can be munged relatively easily. Alpha
is a big platform for RedHat.
It would be very valid to apply Uncle George's patches to a 6.5.2
alpha-only release. If we had an alpha-only release, we would apply
them too.
Our problem is that minor releases don't get the same cross-platform
testing as major releases.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 14:13:45 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA39055
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 14:13:30 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id OAA02974;
Mon, 13 Sep 1999 14:13:12 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Bruce Momjian <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
Date: Mon, 13 Sep 1999 14:00:07 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
Cc: Oleg Bartunov <oleg@sai.msu.su>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
References: <199909131755.NAA23592@candle.pha.pa.us>
MIME-Version: 1.0
Message-Id: <99091314130500.00567@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
On Mon, 13 Sep 1999, Bruce Momjian wrote:
Ok, mung time, then. That means RedHat will be releasing 6.5.1 with
RedHat 6.1, unless those patches can be munged relatively easily. Alpha
is a big platform for RedHat.It would be very valid to apply Uncle George's patches to a 6.5.2
alpha-only release. If we had an alpha-only release, we would apply
them too.
Oh, I understand. Somehow or another I thought 6.5.2 had those patches
integrated. My error.
Our problem is that minor releases don't get the same cross-platform
testing as major releases.
I understand -- I am patch-munging as I write this, after booting into RedHat 6
on my notebook. If Ryan K is still around, he may find it easier going, as he
did the backpatch to 6.5.1. There are a couple of failed hunks, and some
reverses. We'll see how it goes.
Lamar Owen
WGCR Internet Radio
From bouncefilter Mon Sep 13 14:22:45 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 OAA40336
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 14:22:36 -0400 (EDT) (envelope-from leon@udmnet.ru)
Received: from udmnet.ru (U118.dialup.udm.net [192.168.53.118])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id XAA19525;
Mon, 13 Sep 1999 23:20:44 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37DD4046.51780F00@udmnet.ru>
Date: Mon, 13 Sep 1999 23:19:50 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Status report: long-query-string changes
References: <9815.937234399@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Leon <leon@udmnet.ru> writes:
A simple fix would be to check the current size after lexing of that
accumulated string buffer, and if it is non-zero then elog(ERROR) a
complaint. Perhaps a more general fix would be to ensure that you are
never in an exclusive state after all tokens are processed, but I'm
not sure how to do that.The solution is obvious - to eliminate exclusive states entirely!
Banzai!!!Can we do that? Seems like a more likely approach is to ensure that
all of the lexer states have rules that ensure they terminate (or
raise an error, as for unterminated quoted string) at end of input.
I do think checking the token buffer is a hack, and changing the rules
a cleaner solution...
Hmm, yea, you are right. It is much simpler solution. We can check
condition in myinput() and input() when we are going to return
end-of-input (YYSTATE == INITIAL), and raise an error if that's not so.
Well, I give up my idea of total extermination of start conditions :)
BTW, while eyeing the scan.l again, I noticed that C - style comments
can also contain bugs, but I am not completely sure.
--
Leon.
-------
He knows he'll never have to answer for any of his theories actually
being put to test. If they were, they would be contaminated by reality.
From bouncefilter Mon Sep 13 14:29:45 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 OAA41221
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 14:29:17 -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 CAA12312;
Tue, 14 Sep 1999 02:22:40 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37DD40F0.8164BA32@krs.ru>
Date: Tue, 14 Sep 1999 02:22:40 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org, Michael Simms <grim@argh.demon.co.uk>
Subject: Re: [HACKERS] Fixing Simms' vacuum problems
References: <15133.937072666@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
So, it looks like a solution involves two components: first, being more
careful to lock system relations appropriately, and second, being sure
that SI messages are seen soon enough. I think the read-SI-messages-
at-lock-time code that's already in place for 6.6 will be sufficient for
the second point, if we are religious about acquiring appropriate locks.
(BTW, I think that in most cases an appropriate lock on a system table
will be less strong than AccessExclusiveLock --- Vadim, do you agree?)
ExclusiveLock should be ok.
Vadim
From bouncefilter Mon Sep 13 14:38:45 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 OAA42657
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 14:37:52 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id CAA12329;
Tue, 14 Sep 1999 02:30:33 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37DD42C9.B360721B@krs.ru>
Date: Tue, 14 Sep 1999 02:30:33 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, Michael Simms <grim@argh.demon.co.uk>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
References: <13452.937004740@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Also, rather than running around and adding locks to every single
place that calls heap_open or heap_close, I wonder whether we shouldn't
have heap_open/heap_close themselves automatically grab or release
at least a minimal lock (AccessShareLock, I suppose).
This could result in deadlocks...
Or maybe better: change heap_open/heap_openr/heap_close to take an
additional parameter specifying the kind of lock to grab. That'd still
mean having to visit all the call sites, but it would force people to
think about the issue in future rather than forgetting to lock a table
they're accessing.
This way is better.
Vadim
From bouncefilter Mon Sep 13 14:53:45 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA45548
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 14:53:31 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id OAA27525;
Mon, 13 Sep 1999 14:52:54 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909131852.OAA27525@candle.pha.pa.us>
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
In-Reply-To: <37DD42C9.B360721B@krs.ru> from Vadim Mikheev at "Sep 14,
1999 02:30:33 am"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 13 Sep 1999 14:52:54 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
Also, rather than running around and adding locks to every single
place that calls heap_open or heap_close, I wonder whether we shouldn't
have heap_open/heap_close themselves automatically grab or release
at least a minimal lock (AccessShareLock, I suppose).This could result in deadlocks...
Or maybe better: change heap_open/heap_openr/heap_close to take an
additional parameter specifying the kind of lock to grab. That'd still
mean having to visit all the call sites, but it would force people to
think about the issue in future rather than forgetting to lock a table
they're accessing.This way is better.
Just a reminder. heap_getnext() already locks the _buffer_, and
heap_fetch() requires you pass a variable to hold the buffer number, so
you can release the buffer lock when you are done.
This was not the case in < 6.4 releases, and there is no reason not to
add additional parameters to function calls like I did for heap_fetch() if
it makes sense.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 16:03:46 1999
Received: from idiom.com (root@[209.157.64.1])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA55798
for <pgsql-hackers@hub.org>; Mon, 13 Sep 1999 16:03:11 -0400 (EDT)
(envelope-from jason@idiom.com)
Received: from idiom.com (jason@localhost [127.0.0.1])
by idiom.com (8.9.3/8.9.3) with ESMTP id NAA91808;
Mon, 13 Sep 1999 13:03:06 -0700 (PDT)
Message-Id: <199909132003.NAA91808@idiom.com>
To: Peter Mount <petermount@it.maidstone.gov.uk>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] jdbc1 large objects and 651 -- does it work for any one
In-reply-to: Your message of "Mon, 13 Sep 1999 07:39:01 BST."
<1B3D5E532D18D311861A00600865478C25E5B9@exchange1.nt.maidstone.gov.uk>
Date: Mon, 13 Sep 1999 13:03:05 -0700
From: Jason Venner <jason@idiom.com>
Okay, I turned autocommit off (used to have to be autocommit on in
6.3.2) Note: I am running --enable-cassert At the current time there
are 2 open connections to the database, one essentially idle, the
other doing the image work.
I store about 3200 LO's, and on commit get the following
from the java
about to update on 650697 backup/19990911-175649/6654 4
about to update on 650698 backup/19990911-175649/6655 3
The backend has broken the connection. Possibly the action you have attempted has caused it to close.
at postgresql.PG_Stream.ReceiveChar(PG_Stream.java:173)[1] Done bin/postmaster -N 128 -d 3 -i >& /tmp/pgl\
og
at postgresql.Connection.ExecSQL(Connection.java:309)
at postgresql.jdbc1.Connection.commit(Connection.java:173)
at RestoreBlobs.restoreWithLocks(RestoreBlobs.java:72)
at RestoreBlobs.main(RestoreBlobs.java:301)
./db_restore_script: unable to restore all of the images, failed on 1
[note the postmaster bailed]
StartTransactionCommand
query: update invoice set invoice = 712005 where seq = 98
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
query: update invoice set invoice = 712020 where seq = 99
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
CommitTransactionCommand
StartTransactionCommand
query: update invoice set invoice = 712035 where seq = 103
ProcessQuery
CommitTransactionCommand
StartTransactionCommand
query: commit
ProcessUtility: commit
CommitTransactionCommand
NOTICE: LockReleaseAll: xid loop detected, giving up
StartTransactionCommand
query: begin
ProcessUtility: begin
CommitTransactionCommand
StartTransactionCommand
query: commit
ProcessUtility: commit
NOTICE: SIReadEntryData: cache state reset
TRAP: Failed Assertion("!(RelationNameCache->hctl->nkeys == 10):", File: "relcache.c", Line: 1458)
!(RelationNameCache->hctl->nkeys == 10) (0) [No such file or directory]
bin/postmaster: reaping dead processes...
bin/postmaster: CleanupProc: pid 9768 exited with status 134
bin/postmaster: CleanupProc: sending SIGUSR1 to process 9759
NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.
bin/postmaster: CleanupProc: sending SIGUSR1 to process 9756
NOTICE: Message from PostgreSQL backend:
The Postmaster has informed me that some other backend died abnormally and possibly corrupted shared memory.
I have rolled back the current transaction and am going to terminate your database system connection and exit.
Please reconnect to the database system and repeat your query.
bin/postmaster: CleanupProc: reinitializing shared memory and semaphores
shmem_exit(0) [#0]
binding ShmemCreate(key=52df3d, size=10292224)
IpcMemoryCreate: shmget failed (Cannot allocate memory) key=5431101, size=10292224, permission=600
FATAL 1: ShmemCreate: cannot create region
proc_exit(0) [#0]
shmem_exit(0) [#0]
exit(0)
From bouncefilter Mon Sep 13 16:27:46 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA58804
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 16:27:29 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
Received: from pop.dn.net (pm-26.ppp.wdc.dn.net [207.226.188.26])
by postal.dn.net (8.9.3/postal) with ESMTP id QAA19465
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 16:26:51 -0400 (EDT)
Sender: matuser@postal.dn.net
Message-ID: <37DD6380.2E044072@pop.dn.net>
Date: Mon, 13 Sep 1999 20:50:08 +0000
From: Bernard Frankpitt <frankpit@pop.dn.net>
Organization: AIMS
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.32 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgreSQL.org
Subject: Patch for user-defined C-language functions
Content-Type: multipart/mixed; boundary="------------6E0CDC28E89A3B3831CBD174"
This is a multi-part message in MIME format.
--------------6E0CDC28E89A3B3831CBD174
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi all,
I have been working with user defined types and user defined c
functions. One problem that I have encountered with the function
manager is that it does not allow the user to define type conversion
functions that convert between user types. For instance if mytype1,
mytype2, and mytype3 are three Postgresql user types, and if I wish to
define Postgresql conversion functions like
CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so'
LANGUAGE 'C'
CREATE FUNCTION mytype3 ( mytype1 )
RETURNS mytype3
AS 'mytypes.so'
LANGUAGE 'C'
I run into problems, because the Postgresql dynamic loader would look
for a single link symbol, mytype3, for both pieces of object code. If
I just change the name of one of the Postgresql functions (to make the
symbols distinct), the automatic type conversion that Postgresql uses,
for example, when matching operators to arguments no longer finds the
type conversion function.
The solution that I propose, and have implemented in the attatched
patch extends the CREATE FUNCTION syntax as follows. In the first case
above I use the link symbol mytype2_to_mytype3 for the link object
that implements the first conversion function, and define the
Postgresql operator with the following syntax
CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so', 'mytype2_to_mytype3'
LANGUAGE 'C'
The syntax for the AS clause, which was 'AS <link-file>' becomes
AS <link_file>[, <link_name>]
Specification of the link_name is optional, and not needed if the link
name is the same as the Postgresql function name.
The patch includes changes to the parser to include the altered
syntax, changes to the ProcedureStmt node in nodes/parsenodes.h,
changes to commands/define.c to handle the extra information in the AS
clause, and changes to utils/fmgr/dfmgr.c that alter the way that the
dynamic loader figures out what link symbol to use. I store the
string for the link symbol in the prosrc text attribute of the pg_proc
table which is currently unused in rows that reference dynamically
loaded
functions.
Bernie Frankpitt
--------------6E0CDC28E89A3B3831CBD174
Content-Type: application/octet-stream;
name="CreateProcedure.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="CreateProcedure.patch"
KioqIC4vc3JjL2JhY2tlbmQvY29tbWFuZHMvZGVmaW5lLmMub3JpZwlNb24gU2VwIDEzIDE0
OjMwOjU4IDE5OTkKLS0tIC4vc3JjL2JhY2tlbmQvY29tbWFuZHMvZGVmaW5lLmMJTW9uIFNl
cCAxMyAxNTo1Mzo0NyAxOTk5CioqKioqKioqKioqKioqKgoqKiogMTc4LDIwMCAqKioqCiAg
fQogIAogIAogIAogIHN0YXRpYyB2b2lkCiEgaW50ZXJwcmV0X0FTX2NsYXVzZShjb25zdCBj
aGFyICpsYW5ndWFnZU5hbWUsIGNvbnN0IGNoYXIgKmFzLAogIAkJCQkJY2hhciAqKnByb3Ny
Y19zdHJfcCwgY2hhciAqKnByb2Jpbl9zdHJfcCkKICB7CiAgCiAgCWlmIChzdHJjbXAobGFu
Z3VhZ2VOYW1lLCAiQyIpID09IDApCiAgCXsKISAJCS8qIEZvciAiQyIgbGFuZ3VhZ2UsIHN0
b3JlIHRoZSBnaXZlbiBzdHJpbmcgaW4gcHJvYmluICovCiEgCQkqcHJvc3JjX3N0cl9wID0g
Ii0iOwohIAkJKnByb2Jpbl9zdHJfcCA9IChjaGFyICopIGFzOwogIAl9CiAgCWVsc2UKICAJ
ewohIAkJLyogRXZlcnl0aGluZyBlbHNlIHdhbnRzIHRoZSBnaXZlbiBzdHJpbmcgaW4gcHJv
c3JjICovCiEgCQkqcHJvc3JjX3N0cl9wID0gKGNoYXIgKikgYXM7CiAgCQkqcHJvYmluX3N0
cl9wID0gIi0iOwogIAl9CiAgfQogIAotLS0gMTc4LDIyMiAtLS0tCiAgfQogIAogIAorIC8q
CisgICogRm9yIGEgZHluYW1pY2FsbHkgbGlua2VkIEMgbGFuZ3VhZ2Ugb2JqZWN0LCB0aGUg
Zm9ybSBvZiB0aGUgY2xhdXNlIGlzCisgICoKKyAgKgkgICBBUyA8b2JqZWN0IGZpbGUgbmFt
ZT4gWywgPGxpbmsgc3ltYm9sIG5hbWU+IF0KKyAgKgorICAqIEluIGFsbCBvdGhlciBjYXNl
cworICAqCisgICoJICAgQVMgPG9iamVjdCByZWZlcmVuY2UsIG9yIHNxbCBjb2RlPgorICAq
CisgICovCiAgCiAgc3RhdGljIHZvaWQKISBpbnRlcnByZXRfQVNfY2xhdXNlKGNvbnN0IGNo
YXIgKmxhbmd1YWdlTmFtZSwgY29uc3QgTGlzdCAqYXMsCiAgCQkJCQljaGFyICoqcHJvc3Jj
X3N0cl9wLCBjaGFyICoqcHJvYmluX3N0cl9wKQogIHsKKyAJQXNzZXJ0KGFzICE9IE5JTCk7
CiAgCiAgCWlmIChzdHJjbXAobGFuZ3VhZ2VOYW1lLCAiQyIpID09IDApCiAgCXsKISAKISAJ
CS8qCiEgCQkgKiBGb3IgIkMiIGxhbmd1YWdlLCBzdG9yZSB0aGUgZmlsZSBuYW1lIGluIHBy
b2JpbiBhbmQsIHdoZW4KISAJCSAqIGdpdmVuLCB0aGUgbGluayBzeW1ib2wgbmFtZSBpbiBw
cm9zcmMuCiEgCQkgKi8KISAJCSpwcm9iaW5fc3RyX3AgPSBzdHJWYWwobGZpcnN0KGFzKSk7
CiEgCQlpZiAobG5leHQoYXMpID09IE5VTEwpCiEgCQkJKnByb3NyY19zdHJfcCA9ICItIjsK
ISAJCWVsc2UKISAJCQkqcHJvc3JjX3N0cl9wID0gc3RyVmFsKGxzZWNvbmQoYXMpKTsKICAJ
fQogIAllbHNlCiAgCXsKISAJCS8qIEV2ZXJ5dGhpbmcgZWxzZSB3YW50cyB0aGUgZ2l2ZW4g
c3RyaW5nIGluIHByb3NyYy4gKi8KISAJCSpwcm9zcmNfc3RyX3AgPSBzdHJWYWwobGZpcnN0
KGFzKSk7CiAgCQkqcHJvYmluX3N0cl9wID0gIi0iOworIAorIAkJaWYgKGxuZXh0KGFzKSAh
PSBOVUxMKQorIAkJCWVsb2coRVJST1IsICJDUkVBVEUgRlVOQ1RJT046IHBhcnNlIGVycm9y
IGluICdBUyAlcywgJXMnLiIsCisgCQkJCSBzdHJWYWwobGZpcnN0KGFzKSksIHN0clZhbChs
c2Vjb25kKGFzKSkpOwogIAl9CiAgfQogIAoqKiogLi9zcmMvYmFja2VuZC9wYXJzZXIvZ3Jh
bS55Lm9yaWcJTW9uIFNlcCAxMyAxMzoyNTo1NyAxOTk5Ci0tLSAuL3NyYy9iYWNrZW5kL3Bh
cnNlci9ncmFtLnkJTW9uIFNlcCAxMyAxNDowMDoxOCAxOTk5CioqKioqKioqKioqKioqKgoq
KiogMTYyLDE2OCAqKioqCiAgJXR5cGUgPGxpc3Q+CXN0bXRibG9jaywgc3RtdG11bHRpLAog
IAkJcmVzdWx0LCByZWxhdGlvbl9uYW1lX2xpc3QsIE9wdFRhYmxlRWxlbWVudExpc3QsCiAg
CQlPcHRJbmhlcml0LCBkZWZpbml0aW9uLAohIAkJb3B0X3dpdGgsIGZ1bmNfYXJncywgZnVu
Y19hcmdzX2xpc3QsCiAgCQlvcGVyX2FyZ3R5cGVzLCBSdWxlQWN0aW9uTGlzdCwgUnVsZUFj
dGlvbkJsb2NrLCBSdWxlQWN0aW9uTXVsdGksCiAgCQlvcHRfY29sdW1uX2xpc3QsIGNvbHVt
bkxpc3QsIG9wdF92YV9saXN0LCB2YV9saXN0LAogIAkJc29ydF9jbGF1c2UsIHNvcnRieV9s
aXN0LCBpbmRleF9wYXJhbXMsIGluZGV4X2xpc3QsIG5hbWVfbGlzdCwKLS0tIDE2MiwxNjgg
LS0tLQogICV0eXBlIDxsaXN0PglzdG10YmxvY2ssIHN0bXRtdWx0aSwKICAJCXJlc3VsdCwg
cmVsYXRpb25fbmFtZV9saXN0LCBPcHRUYWJsZUVsZW1lbnRMaXN0LAogIAkJT3B0SW5oZXJp
dCwgZGVmaW5pdGlvbiwKISAJCW9wdF93aXRoLCBmdW5jX2FyZ3MsIGZ1bmNfYXJnc19saXN0
LCBmdW5jX2FzLAogIAkJb3Blcl9hcmd0eXBlcywgUnVsZUFjdGlvbkxpc3QsIFJ1bGVBY3Rp
b25CbG9jaywgUnVsZUFjdGlvbk11bHRpLAogIAkJb3B0X2NvbHVtbl9saXN0LCBjb2x1bW5M
aXN0LCBvcHRfdmFfbGlzdCwgdmFfbGlzdCwKICAJCXNvcnRfY2xhdXNlLCBzb3J0YnlfbGlz
dCwgaW5kZXhfcGFyYW1zLCBpbmRleF9saXN0LCBuYW1lX2xpc3QsCioqKioqKioqKioqKioq
KgoqKiogMTkwNywxOTEzICoqKioKICAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCiAgCiAg
UHJvY2VkdXJlU3RtdDoJQ1JFQVRFIEZVTkNUSU9OIGZ1bmNfbmFtZSBmdW5jX2FyZ3MKISAJ
CQkgUkVUVVJOUyBmdW5jX3JldHVybiBvcHRfd2l0aCBBUyBTY29uc3QgTEFOR1VBR0UgU2Nv
bnN0CiAgCQkJCXsKICAJCQkJCVByb2NlZHVyZVN0bXQgKm4gPSBtYWtlTm9kZShQcm9jZWR1
cmVTdG10KTsKICAJCQkJCW4tPmZ1bmNuYW1lID0gJDM7Ci0tLSAxOTA3LDE5MTMgLS0tLQog
ICAqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKi8KICAKICBQcm9jZWR1cmVTdG10OglDUkVBVEUg
RlVOQ1RJT04gZnVuY19uYW1lIGZ1bmNfYXJncwohIAkJCSBSRVRVUk5TIGZ1bmNfcmV0dXJu
IG9wdF93aXRoIEFTIGZ1bmNfYXMgTEFOR1VBR0UgU2NvbnN0CiAgCQkJCXsKICAJCQkJCVBy
b2NlZHVyZVN0bXQgKm4gPSBtYWtlTm9kZShQcm9jZWR1cmVTdG10KTsKICAJCQkJCW4tPmZ1
bmNuYW1lID0gJDM7CioqKioqKioqKioqKioqKgoqKiogMTkzMSwxOTM2ICoqKioKLS0tIDE5
MzEsMTk0MiAtLS0tCiAgCQkJCXsJJCQgPSBsY29ucyhtYWtlU3RyaW5nKCQxKSxOSUwpOyB9
CiAgCQl8IGZ1bmNfYXJnc19saXN0ICcsJyBUeXBlSWQKICAJCQkJewkkJCA9IGxhcHBlbmQo
JDEsbWFrZVN0cmluZygkMykpOyB9CisgCQk7CisgCisgZnVuY19hczogU2NvbnN0CQorIAkJ
CQl7ICAgJCQgPSBsY29ucyhtYWtlU3RyaW5nKCQxKSxOSUwpOyB9CisgCQl8IFNjb25zdCAn
LCcgU2NvbnN0CisgCQkJCXsgCSQkID0gbGFwcGVuZChsY29ucyhtYWtlU3RyaW5nKCQxKSxO
SUwpLCBtYWtlU3RyaW5nKCQzKSk7IH0KICAJCTsKICAKICBmdW5jX3JldHVybjogIHNldF9v
cHQgVHlwZUlkCioqKiAuL3NyYy9iYWNrZW5kL3V0aWxzL2ZtZ3IvZGZtZ3IuYy5vcmlnCU1v
biBTZXAgMTMgMTM6MjU6NTcgMTk5OQotLS0gLi9zcmMvYmFja2VuZC91dGlscy9mbWdyL2Rm
bWdyLmMJTW9uIFNlcCAxMyAxNTo1Nzo0NyAxOTk5CioqKioqKioqKioqKioqKgoqKiogNDIs
NDkgKioqKgogIAlIZWFwVHVwbGUJcHJvY2VkdXJlVHVwbGU7CiAgCUZvcm1fcGdfcHJvYyBw
cm9jZWR1cmVTdHJ1Y3Q7CiAgCWNoYXIJICAgKnByb25hbWUsCiEgCQkJICAgKnByb2JpbnN0
cmluZzsKICAJRGF0dW0JCXByb2JpbmF0dHI7CiAgCWZ1bmNfcHRyCXVzZXJfZm47CiAgCVJl
bGF0aW9uCXJlbDsKICAJYm9vbAkJaXNudWxsOwotLS0gNDIsNTIgLS0tLQogIAlIZWFwVHVw
bGUJcHJvY2VkdXJlVHVwbGU7CiAgCUZvcm1fcGdfcHJvYyBwcm9jZWR1cmVTdHJ1Y3Q7CiAg
CWNoYXIJICAgKnByb25hbWUsCiEgCQkJICAgKnByb2JpbnN0cmluZywKISAJCQkgICAqcHJv
c3Jjc3RyaW5nLAohIAkJCSAgICpsaW5rc3ltYm9sOwogIAlEYXR1bQkJcHJvYmluYXR0cjsK
KyAJRGF0dW0JCXByb3NyY2F0dHI7CiAgCWZ1bmNfcHRyCXVzZXJfZm47CiAgCVJlbGF0aW9u
CXJlbDsKICAJYm9vbAkJaXNudWxsOwoqKioqKioqKioqKioqKioKKioqIDk5LDEwNSAqKioq
CiAgCX0KICAJcHJvYmluc3RyaW5nID0gdGV4dG91dCgoc3RydWN0IHZhcmxlbmEgKikgcHJv
YmluYXR0cik7CiAgCiEgCXVzZXJfZm4gPSBoYW5kbGVfbG9hZChwcm9iaW5zdHJpbmcsIHBy
b25hbWUpOwogIAogIAlwcm9jZWR1cmVJZF9zYXZlID0gcHJvY2VkdXJlSWQ7CiAgCXVzZXJf
Zm5fc2F2ZSA9IHVzZXJfZm47Ci0tLSAxMDIsMTMzIC0tLS0KICAJfQogIAlwcm9iaW5zdHJp
bmcgPSB0ZXh0b3V0KChzdHJ1Y3QgdmFybGVuYSAqKSBwcm9iaW5hdHRyKTsKICAKISAJcHJv
c3JjYXR0ciA9IGhlYXBfZ2V0YXR0cihwcm9jZWR1cmVUdXBsZSwKISAJCQkJCQkJICBBbnVt
X3BnX3Byb2NfcHJvc3JjLAohIAkJCQkJCQkgIFJlbGF0aW9uR2V0RGVzY3IocmVsKSwgJmlz
bnVsbCk7CiEgCiEgCWlmIChpc251bGwpCiEgCXsJCQkJCQkJLyogVXNlIHRoZSBwcm9uYW1l
IGZvciB0aGUgbGluayBzeW1ib2wgKi8KISAJCWxpbmtzeW1ib2wgPSBwcm9uYW1lOwohIAl9
CiEgCWVsc2UgaWYgKCFQb2ludGVySXNWYWxpZChwcm9zcmNhdHRyKSkKISAJewkJCQkJCQkv
KiBwZ19wcm9jIG11c3QgYmUgbWVzc2VkIHVwISAqLwohIAkJaGVhcF9jbG9zZShyZWwpOwoh
IAkJZWxvZyhFUlJPUiwgImZtZ3I6IENvdWxkIG5vdCBleHRyYWN0IHByb3NyYyBmb3IgJXUg
ZnJvbSAlcyIsCiEgCQkJIHByb2NlZHVyZUlkLCBQcm9jZWR1cmVSZWxhdGlvbk5hbWUpOwoh
IAkJcmV0dXJuIChmdW5jX3B0cikgTlVMTDsKISAJfQohIAllbHNlCiEgCXsJCQkJCQkJLyog
VGhlIHRleHQgaW4gcHJvc3JjYXR0ciBpcyBlaXRoZXIgIi0iIG9yCiEgCQkJCQkJCQkgKiBh
IGxpbmsgc3ltYm9sICovCiEgCQlwcm9zcmNzdHJpbmcgPSB0ZXh0b3V0KChzdHJ1Y3QgdmFy
bGVuYSAqKSBwcm9zcmNhdHRyKTsKISAJCWlmIChzdHJjbXAocHJvc3Jjc3RyaW5nLCAiLSIp
ID09IDApCiEgCQkJbGlua3N5bWJvbCA9IHByb25hbWU7CiEgCQllbHNlCiEgCQkJbGlua3N5
bWJvbCA9IHByb3NyY3N0cmluZzsKISAJfQohIAohIAl1c2VyX2ZuID0gaGFuZGxlX2xvYWQo
cHJvYmluc3RyaW5nLCBsaW5rc3ltYm9sKTsKICAKICAJcHJvY2VkdXJlSWRfc2F2ZSA9IHBy
b2NlZHVyZUlkOwogIAl1c2VyX2ZuX3NhdmUgPSB1c2VyX2ZuOwoqKiogLi9zcmMvaW5jbHVk
ZS9ub2Rlcy9wYXJzZW5vZGVzLmgub3JpZwlNb24gU2VwIDEzIDEzOjI1OjU4IDE5OTkKLS0t
IC4vc3JjL2luY2x1ZGUvbm9kZXMvcGFyc2Vub2Rlcy5oCU1vbiBTZXAgMTMgMTU6NTk6MjYg
MTk5OQoqKioqKioqKioqKioqKioKKioqIDcwLDc2ICoqKioKICAJLyogaW50ZXJuYWwgdG8g
cGxhbm5lciAqLwogIAlMaXN0CSAgICpiYXNlX3JlbF9saXN0OwkvKiBsaXN0IG9mIGJhc2Ut
cmVsYXRpb24gUmVsT3B0SW5mb3MgKi8KICAJTGlzdAkgICAqam9pbl9yZWxfbGlzdDsJLyog
bGlzdCBvZiBqb2luLXJlbGF0aW9uIFJlbE9wdEluZm9zICovCiEgCUxpc3QJICAgKnF1ZXJ5
X3BhdGhrZXlzOwkvKiBwYXRoa2V5cyBmb3IgcXVlcnlfcGxhbm5lcigpJ3MgcmVzdWx0ICov
CiAgfSBRdWVyeTsKICAKICAKLS0tIDcwLDc2IC0tLS0KICAJLyogaW50ZXJuYWwgdG8gcGxh
bm5lciAqLwogIAlMaXN0CSAgICpiYXNlX3JlbF9saXN0OwkvKiBsaXN0IG9mIGJhc2UtcmVs
YXRpb24gUmVsT3B0SW5mb3MgKi8KICAJTGlzdAkgICAqam9pbl9yZWxfbGlzdDsJLyogbGlz
dCBvZiBqb2luLXJlbGF0aW9uIFJlbE9wdEluZm9zICovCiEgCUxpc3QJICAgKnF1ZXJ5X3Bh
dGhrZXlzOyAvKiBwYXRoa2V5cyBmb3IgcXVlcnlfcGxhbm5lcigpJ3MgcmVzdWx0ICovCiAg
fSBRdWVyeTsKICAKICAKKioqKioqKioqKioqKioqCioqKiAzNTEsMzU3ICoqKioKICAJTm9k
ZQkgICAqcmV0dXJuVHlwZTsJCS8qIHRoZSByZXR1cm4gdHlwZSAoYXMgYSBzdHJpbmcgb3Ig
YQogIAkJCQkJCQkJICogVHlwZU5hbWUgKGllLnNldG9mKSAqLwogIAlMaXN0CSAgICp3aXRo
Q2xhdXNlOwkJLyogYSBsaXN0IG9mIFBhcmFtU3RyaW5nICovCiEgCWNoYXIJICAgKmFzOwkJ
CQkvKiB0aGUgU1FMIHN0YXRlbWVudCBvciBmaWxlbmFtZSAqLwogIAljaGFyCSAgICpsYW5n
dWFnZTsJCS8qIEMgb3IgU1FMICovCiAgfSBQcm9jZWR1cmVTdG10OwogIAotLS0gMzUxLDM1
NyAtLS0tCiAgCU5vZGUJICAgKnJldHVyblR5cGU7CQkvKiB0aGUgcmV0dXJuIHR5cGUgKGFz
IGEgc3RyaW5nIG9yIGEKICAJCQkJCQkJCSAqIFR5cGVOYW1lIChpZS5zZXRvZikgKi8KICAJ
TGlzdAkgICAqd2l0aENsYXVzZTsJCS8qIGEgbGlzdCBvZiBQYXJhbVN0cmluZyAqLwohIAlM
aXN0CSAgICphczsJCQkJLyogdGhlIFNRTCBzdGF0ZW1lbnQgb3IgZmlsZW5hbWUgKi8KICAJ
Y2hhcgkgICAqbGFuZ3VhZ2U7CQkvKiBDIG9yIFNRTCAqLwogIH0gUHJvY2VkdXJlU3RtdDsK
ICAKKioqKioqKioqKioqKioqCioqKiA4MjYsODMzICoqKioKICB7CiAgCU5vZGVUYWcJCXR5
cGU7CiAgCWNoYXIJICAgKm5hbWU7CQkJLyogY29sdW1uIG5hbWUgb3IgTlVMTCAqLwohIAlM
aXN0CSAgICppbmRpcmVjdGlvbjsJLyogc3Vic2NyaXB0cyBmb3IgZGVzdGluYXRpb24gY29s
dW1uLCBvciBOSUwgKi8KISAJTm9kZQkgICAqdmFsOwkJCS8qIHRoZSB2YWx1ZSBleHByZXNz
aW9uIHRvIGNvbXB1dGUgb3IgYXNzaWduICovCiAgfSBSZXNUYXJnZXQ7CiAgCiAgLyoKLS0t
IDgyNiw4MzUgLS0tLQogIHsKICAJTm9kZVRhZwkJdHlwZTsKICAJY2hhcgkgICAqbmFtZTsJ
CQkvKiBjb2x1bW4gbmFtZSBvciBOVUxMICovCiEgCUxpc3QJICAgKmluZGlyZWN0aW9uOwkv
KiBzdWJzY3JpcHRzIGZvciBkZXN0aW5hdGlvbiBjb2x1bW4sIG9yCiEgCQkJCQkJCQkgKiBO
SUwgKi8KISAJTm9kZQkgICAqdmFsOwkJCS8qIHRoZSB2YWx1ZSBleHByZXNzaW9uIHRvIGNv
bXB1dGUgb3IKISAJCQkJCQkJCSAqIGFzc2lnbiAqLwogIH0gUmVzVGFyZ2V0OwogIAogIC8q
CioqKioqKioqKioqKioqKgoqKiogOTYwLDk2NiAqKioqCiAgdHlwZWRlZiBzdHJ1Y3QgU29y
dENsYXVzZQogIHsKICAJTm9kZVRhZwkJdHlwZTsKISAJSW5kZXgJCXRsZVNvcnRHcm91cFJl
ZjsgLyogcmVmZXJlbmNlIGludG8gdGFyZ2V0bGlzdCAqLwogIAlPaWQJCQlzb3J0b3A7CQkJ
LyogdGhlIHNvcnQgb3BlcmF0b3IgdG8gdXNlICovCiAgfSBTb3J0Q2xhdXNlOwogIAotLS0g
OTYyLDk2OCAtLS0tCiAgdHlwZWRlZiBzdHJ1Y3QgU29ydENsYXVzZQogIHsKICAJTm9kZVRh
ZwkJdHlwZTsKISAJSW5kZXgJCXRsZVNvcnRHcm91cFJlZjsvKiByZWZlcmVuY2UgaW50byB0
YXJnZXRsaXN0ICovCiAgCU9pZAkJCXNvcnRvcDsJCQkvKiB0aGUgc29ydCBvcGVyYXRvciB0
byB1c2UgKi8KICB9IFNvcnRDbGF1c2U7CiAgCioqKiAuL3NyYy9pbnRlcmZhY2VzL2VjcGcv
cHJlcHJvYy9wcmVwcm9jLnkub3JpZwlNb24gU2VwIDEzIDEzOjI1OjU4IDE5OTkKLS0tIC4v
c3JjL2ludGVyZmFjZXMvZWNwZy9wcmVwcm9jL3ByZXByb2MueQlNb24gU2VwIDEzIDE0OjU3
OjQwIDE5OTkKKioqKioqKioqKioqKioqCioqKiA3OTksODA1ICoqKioKICAldHlwZSAgPHN0
cj4gICAgb3B0X2FuYWx5emUgb3B0X3ZhX2xpc3QgdmFfbGlzdCBFeHBsYWluU3RtdCBpbmRl
eF9wYXJhbXMKICAldHlwZSAgPHN0cj4gICAgaW5kZXhfbGlzdCBmdW5jX2luZGV4IGluZGV4
X2VsZW0gb3B0X3R5cGUgb3B0X2NsYXNzIGFjY2Vzc19tZXRob2RfY2xhdXNlCiAgJXR5cGUg
IDxzdHI+ICAgIGluZGV4X29wdF91bmlxdWUgSW5kZXhTdG10IHNldF9vcHQgZnVuY19yZXR1
cm4gZGVmX3Jlc3QKISAldHlwZSAgPHN0cj4gICAgZnVuY19hcmdzX2xpc3QgZnVuY19hcmdz
IG9wdF93aXRoIFByb2NlZHVyZVN0bXQgZGVmX2FyZwogICV0eXBlICA8c3RyPiAgICBkZWZf
ZWxlbSBkZWZfbGlzdCBkZWZpbml0aW9uIGRlZl9uYW1lIGRlZl90eXBlIERlZmluZVN0bXQK
ICAldHlwZSAgPHN0cj4gICAgb3B0X2luc3RlYWQgZXZlbnQgZXZlbnRfb2JqZWN0IFJ1bGVB
Y3Rpb25MaXN0LAogICV0eXBlICA8c3RyPglSdWxlQWN0aW9uQmxvY2sgUnVsZUFjdGlvbk11
bHRpIGpvaW5fbGlzdAotLS0gNzk5LDgwNSAtLS0tCiAgJXR5cGUgIDxzdHI+ICAgIG9wdF9h
bmFseXplIG9wdF92YV9saXN0IHZhX2xpc3QgRXhwbGFpblN0bXQgaW5kZXhfcGFyYW1zCiAg
JXR5cGUgIDxzdHI+ICAgIGluZGV4X2xpc3QgZnVuY19pbmRleCBpbmRleF9lbGVtIG9wdF90
eXBlIG9wdF9jbGFzcyBhY2Nlc3NfbWV0aG9kX2NsYXVzZQogICV0eXBlICA8c3RyPiAgICBp
bmRleF9vcHRfdW5pcXVlIEluZGV4U3RtdCBzZXRfb3B0IGZ1bmNfcmV0dXJuIGRlZl9yZXN0
CiEgJXR5cGUgIDxzdHI+ICAgIGZ1bmNfYXMgZnVuY19hcmdzX2xpc3QgZnVuY19hcmdzIG9w
dF93aXRoIFByb2NlZHVyZVN0bXQgZGVmX2FyZwogICV0eXBlICA8c3RyPiAgICBkZWZfZWxl
bSBkZWZfbGlzdCBkZWZpbml0aW9uIGRlZl9uYW1lIGRlZl90eXBlIERlZmluZVN0bXQKICAl
dHlwZSAgPHN0cj4gICAgb3B0X2luc3RlYWQgZXZlbnQgZXZlbnRfb2JqZWN0IFJ1bGVBY3Rp
b25MaXN0LAogICV0eXBlICA8c3RyPglSdWxlQWN0aW9uQmxvY2sgUnVsZUFjdGlvbk11bHRp
IGpvaW5fbGlzdAoqKioqKioqKioqKioqKioKKioqIDIxOTcsMjIwNyAqKioqCiAgICoJCQkJ
CQlbLCBpc2NhY2hhYmxlXSkKICAgKgkJCQkJCVthcmcgaXMgKDx0eXBlLTE+IHsgLCA8dHlw
ZS1uPn0pXQogICAqCQkJCQkJYXMgPGZpbGVuYW1lIG9yIGNvZGUgaW4gbGFuZ3VhZ2UgYXMg
YXBwcm9wcmlhdGU+CiAgICoKICAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCiAgCiAgUHJv
Y2VkdXJlU3RtdDoJQ1JFQVRFIEZVTkNUSU9OIGZ1bmNfbmFtZSBmdW5jX2FyZ3MKISAJCQkg
UkVUVVJOUyBmdW5jX3JldHVybiBvcHRfd2l0aCBBUyBTY29uc3QgTEFOR1VBR0UgU2NvbnN0
CiAgCQkJCXsKICAJCQkJCSQkID0gY2F0Ml9zdHIoY2F0NV9zdHIoY2F0NV9zdHIobWFrZTFf
c3RyKCJjcmVhdGUgZnVuY3Rpb24iKSwgJDMsICQ0LCBtYWtlMV9zdHIoInJldHVybnMiKSwg
JDYpLCAkNywgbWFrZTFfc3RyKCJhcyIpLCAkOSwgbWFrZTFfc3RyKCJsYW5ndWFnZSIpKSwg
JDExKTsKICAJCQkJfQotLS0gMjE5NywyMjA4IC0tLS0KICAgKgkJCQkJCVssIGlzY2FjaGFi
bGVdKQogICAqCQkJCQkJW2FyZyBpcyAoPHR5cGUtMT4geyAsIDx0eXBlLW4+fSldCiAgICoJ
CQkJCQlhcyA8ZmlsZW5hbWUgb3IgY29kZSBpbiBsYW5ndWFnZSBhcyBhcHByb3ByaWF0ZT4K
KyAgKiAgICAgICAgICAgICAgICAgICAgICBbLCA8bGluayBuYW1lIGZvciBkeW5hbWljIGxv
YWRlcj5dCiAgICoKICAgKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKiovCiAgCiAgUHJvY2VkdXJl
U3RtdDoJQ1JFQVRFIEZVTkNUSU9OIGZ1bmNfbmFtZSBmdW5jX2FyZ3MKISAJCQkgUkVUVVJO
UyBmdW5jX3JldHVybiBvcHRfd2l0aCBBUyBmdW5jX2FzIExBTkdVQUdFIFNjb25zdAogIAkJ
CQl7CiAgCQkJCQkkJCA9IGNhdDJfc3RyKGNhdDVfc3RyKGNhdDVfc3RyKG1ha2UxX3N0cigi
Y3JlYXRlIGZ1bmN0aW9uIiksICQzLCAkNCwgbWFrZTFfc3RyKCJyZXR1cm5zIiksICQ2KSwg
JDcsIG1ha2UxX3N0cigiYXMiKSwgJDksIG1ha2UxX3N0cigibGFuZ3VhZ2UiKSksICQxMSk7
CiAgCQkJCX0KKioqKioqKioqKioqKioqCioqKiAyMjE3LDIyMjIgKioqKgotLS0gMjIxOCwy
MjI5IC0tLS0KICBmdW5jX2FyZ3NfbGlzdDogIFR5cGVJZAkJCQl7ICQkID0gJDE7IH0KICAJ
CXwgZnVuY19hcmdzX2xpc3QgJywnIFR5cGVJZAogIAkJCQl7CSQkID0gY2F0M19zdHIoJDEs
IG1ha2UxX3N0cigiLCIpLCAkMyk7IH0KKyAJCTsKKyAKKyBmdW5jX2FzOiAgU2NvbnN0IAor
ICAgICAgICAgICAgICAgICB7ICQkID0gJDE7IH0KKyAgICAgICAgIHwgU2NvbnN0ICcsJyBT
Y29uc3QKKyAJCQkJeyAkJCA9IGNhdDNfc3RyKCQxLCBtYWtlMV9zdHIoIiwiKSwgJDMpOyB9
CiAgCQk7CiAgCiAgZnVuY19yZXR1cm46ICBzZXRfb3B0IFR5cGVJZAo=
--------------6E0CDC28E89A3B3831CBD174--
From bouncefilter Mon Sep 13 16:53:46 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 QAA61839
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 16:53: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 QAA11017;
Mon, 13 Sep 1999 16:51:39 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Vadim Mikheev <vadim@krs.ru>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
In-reply-to: Your message of Mon, 13 Sep 1999 14:52:54 -0400 (EDT)
<199909131852.OAA27525@candle.pha.pa.us>
Date: Mon, 13 Sep 1999 16:51:39 -0400
Message-ID: <11014.937255899@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
Tom Lane wrote:
Or maybe better: change heap_open/heap_openr/heap_close to take an
additional parameter specifying the kind of lock to grab.
This way is better.
... there is no reason not to add additional parameters to function
calls like I did for heap_fetch() if it makes sense.
OK. Another thing that's been on my to-do list is that a lot of places
fail to check for a failure return from heap_open(r), which means you
get a null pointer dereference coredump instead of a useful message if
anything goes wrong. (But, of course, when opening a system table
nothing can ever go wrong ... go wrogn ...)
Here's what I propose:
Add another parameter to heap_open and heap_openr, which can be any of
the lock types currently mentioned in storage/lmgr.h, or "NoLock".
With "NoLock" you get the current behavior: no lock is acquired, and
NULL is returned if the open fails; it's up to the caller to check that
and do something appropriate. Otherwise, the routines will check for
open failure and raise a standard elog(ERROR) if they do not succeed;
furthermore, they will acquire the specified type of lock on the
relation before returning. (And, thanks to the already-in-place call
in LockRelation, any pending SI-inval messages will be read.)
heap_close will also take an additional parameter, which is a lock type
to release the specified lock, or NoLock to release no lock. (Note
that it is often correct not to release the lock acquired at heap_open
during heap_close; in this case, the lock is held till end of
transaction. So, we don't want heap_close to automagically release
whatever lock was acquired by the corresponding heap_open, even if it
were easy to do so which it isn't...)
If I don't hear any objections, I'll get on with implementing that.
regards, tom lane
From bouncefilter Mon Sep 13 16:57:46 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 QAA62338
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 16:57:14 -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 QAA11058;
Mon, 13 Sep 1999 16:56:28 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-reply-to: Your message of Mon, 13 Sep 1999 13:11:11 -0400 (EDT)
<199909131711.NAA22947@candle.pha.pa.us>
Date: Mon, 13 Sep 1999 16:56:28 -0400
Message-ID: <11056.937256188@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
Repair the check for redundant UNIQUE and PRIMARY KEY indices(Tom)
Improve it so that it checks for multi-column constraints(Tom)
Those were Thomas, I believe.
Fix vacuum's memory consumption(Tom)
Reduce the total memory consumption of vacuum(Tom)
And I can't take credit for that either --- Hiroshi and/or Tatsuo get
the credit, IIRC. (BTW, did we patch those into 6.5.*, or only 6.6?)
Update frontend libpq to remove limits on query lengths,
error/notice message lengths, and number of fields per tuple(Tom)
This is *not* in 6.5.*, only 6.6.
regards, tom lane
From bouncefilter Mon Sep 13 17:06:46 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 RAA63241
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 17:04: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 RAA11093;
Mon, 13 Sep 1999 17:01:41 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Lamar Owen <lamar.owen@wgcr.org>, Oleg Bartunov <oleg@sai.msu.su>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-reply-to: Your message of Mon, 13 Sep 1999 13:47:19 -0400 (EDT)
<199909131747.NAA23374@candle.pha.pa.us>
Date: Mon, 13 Sep 1999 17:01:40 -0400
Message-ID: <11091.937256500@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
Hey, Bruce -- did the patches for Alpha get in?? If not, I'll need to
mung Ryan K's/Uncle G's patchset against 6.5.1 to work with 6.5.2.
The bad news is that those patches are too large/significant for a minor
release. They could affect other platforms adversely, so we can't apply
them until 6.6.
Also, most of them were patches for the portability problems in our
function call interface. I still have hopes of redesigning the fmgr
interface completely before 6.6 --- see my message in the hackers
archives for 6/14/99. If we get that done then there'll be no need for
the associated patches. (If we don't, we'd better apply the patches,
since Alpha is not the only platform where there are problems...)
regards, tom lane
From bouncefilter Mon Sep 13 17:23:46 1999
Received: from nsi.edu (amethea.nsi.edu [198.133.185.9])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA65366
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 17:23:31 -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 OAA04983
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 14:23:20 -0700 (PDT)
Sender: reina@nsi.edu
Message-ID: <37DD6E70.B27F2D80@nsi.edu>
Date: Mon, 13 Sep 1999 14:36:48 -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: Is "isolation" a restricted word?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I am trying to make a table with a class called "isolation". For some
reason, I am getting a parser error:
=> create table cell ( isolation text );
ERROR: parser: parse error at or near "isolation"
If I just take off the "n", I get:
=> create table cell ( isolatio text );
CREATE
This table had no problems previously; has the word isolation been used
somewhere else as a SQL word? I can't think of why else I am having
problems with the table (the syntax appears to be correct).
Thanks.
-Tony
From bouncefilter Mon Sep 13 17:46:47 1999
Received: from wallace.ece.rice.edu (root@wallace.ece.rice.edu
[128.42.12.154])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA68691
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 17:46:29 -0400 (EDT)
(envelope-from reedstrm@wallace.ece.rice.edu)
Received: by wallace.ece.rice.edu via sendmail from stdin
id <m11Qdve-000LEEC@wallace.ece.rice.edu> (Debian Smail3.2.0.102)
for pgsql-hackers@postgreSQL.org; Mon, 13 Sep 1999 16:46:26 -0500 (CDT)
Date: Mon, 13 Sep 1999 16:46:26 -0500
From: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
To: "G. Anthony Reina" <reina@nsi.edu>
Cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Is "isolation" a restricted word?
Message-ID: <19990913164626.A32509@wallace.ece.rice.edu>
References: <37DD6E70.B27F2D80@nsi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.3i
In-Reply-To: <37DD6E70.B27F2D80@nsi.edu>;
from G. Anthony Reina on Mon, Sep 13, 1999 at 02:36:48PM -0700
On Mon, Sep 13, 1999 at 02:36:48PM -0700, G. Anthony Reina wrote:
I am trying to make a table with a class called "isolation". For some
reason, I am getting a parser error:=> create table cell ( isolation text );
ERROR: parser: parse error at or near "isolation"If I just take off the "n", I get:
=> create table cell ( isolatio text );
CREATEThis table had no problems previously; has the word isolation been used
somewhere else as a SQL word? I can't think of why else I am having
problems with the table (the syntax appears to be correct).
Yup - here it is in pgsql/src/backend/parser/keywords.c:
...
{"is", IS},
{"isnull", ISNULL},
{"isolation", ISOLATION},
{"join", JOIN},
{"key", KEY},
{"lancompiler", LANCOMPILER},
...
This table should in fact be the definitive guide, since it's the array
that the parser uses ;-)
And it's mentioned in the HISTORY file as part of the MVCC
changes. They're a couple of these 'gotcha' words that are part of
the SQL standard, but hadn't yet been implemented before 6.5 that have
triped up people.
If you have to keep the table name, quote it:
create table cell ( "isolation" text );
But then you'll always have to quote it. I'm stuck with a bunch of
MiXedCaSE tables that I have to do that with.
Ross
--
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
From bouncefilter Mon Sep 13 17:49:47 1999
Received: from nsi.edu (amethea.nsi.edu [198.133.185.9])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA69156
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 17:49: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 OAA05461;
Mon, 13 Sep 1999 14:49:33 -0700 (PDT)
Sender: reina@nsi.edu
Message-ID: <37DD7496.370076EC@nsi.edu>
Date: Mon, 13 Sep 1999 15:03:02 -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: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Is "isolation" a restricted word?
References: <37DD6E70.B27F2D80@nsi.edu>
<19990913164626.A32509@wallace.ece.rice.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
"Ross J. Reedstrom" wrote:
Yup - here it is in pgsql/src/backend/parser/keywords.c:
Thanks Reed. I'll just change it since it's restricted.
-Tony
From bouncefilter Mon Sep 13 18:39:47 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA74485
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 18:39:01 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id SAA02854;
Mon, 13 Sep 1999 18:33:31 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909132233.SAA02854@candle.pha.pa.us>
Subject: Re: [HACKERS] Vacuum analyze bug CAUGHT
In-Reply-To: <11014.937255899@sss.pgh.pa.us> from Tom Lane at "Sep 13,
1999 04:51:39 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 13 Sep 1999 18:33:31 -0400 (EDT)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sounds like a good plan. I found it quite easy to make changes link
this because mkid, and your tool glimpse, lets you pull up all functions
that contain a certain function or call to that function, pull them into
an editor, and away you go.
Here's what I propose:
Add another parameter to heap_open and heap_openr, which can be any of
the lock types currently mentioned in storage/lmgr.h, or "NoLock".
With "NoLock" you get the current behavior: no lock is acquired, and
NULL is returned if the open fails; it's up to the caller to check that
and do something appropriate. Otherwise, the routines will check for
open failure and raise a standard elog(ERROR) if they do not succeed;
furthermore, they will acquire the specified type of lock on the
relation before returning. (And, thanks to the already-in-place call
in LockRelation, any pending SI-inval messages will be read.)heap_close will also take an additional parameter, which is a lock type
to release the specified lock, or NoLock to release no lock. (Note
that it is often correct not to release the lock acquired at heap_open
during heap_close; in this case, the lock is held till end of
transaction. So, we don't want heap_close to automagically release
whatever lock was acquired by the corresponding heap_open, even if it
were easy to do so which it isn't...)If I don't hear any objections, I'll get on with implementing that.
regards, tom lane
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 18:40:47 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA74547
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 18:39:55 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id SAA03255;
Mon, 13 Sep 1999 18:38:18 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909132238.SAA03255@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <11056.937256188@sss.pgh.pa.us> from Tom Lane at "Sep 13,
1999 04:56:28 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 13 Sep 1999 18:38:18 -0400 (EDT)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Bruce Momjian <maillist@candle.pha.pa.us> writes:
Repair the check for redundant UNIQUE and PRIMARY KEY indices(Tom)
Improve it so that it checks for multi-column constraints(Tom)Those were Thomas, I believe.
Done.
Fix vacuum's memory consumption(Tom)
Reduce the total memory consumption of vacuum(Tom)And I can't take credit for that either --- Hiroshi and/or Tatsuo get
the credit, IIRC. (BTW, did we patch those into 6.5.*, or only 6.6?)
Ah, let's give them both credit.
Update frontend libpq to remove limits on query lengths,
error/notice message lengths, and number of fields per tuple(Tom)This is *not* in 6.5.*, only 6.6.
Sorry. Shows up in the that tag log, so something must be in there. I
don't make this stuff up. :-)
Checking...
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 20:20:48 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 UAA85937
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 20:20: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 UAA11682;
Mon, 13 Sep 1999 20:19:55 -0400 (EDT)
To: Bernard Frankpitt <frankpit@pop.dn.net>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Patch for user-defined C-language functions
In-reply-to: Your message of Mon, 13 Sep 1999 20:50:08 +0000
<37DD6380.2E044072@pop.dn.net>
Date: Mon, 13 Sep 1999 20:19:55 -0400
Message-ID: <11680.937268395@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bernard Frankpitt <frankpit@pop.dn.net> writes:
The solution that I propose, and have implemented in the attatched
patch extends the CREATE FUNCTION syntax as follows. In the first case
above I use the link symbol mytype2_to_mytype3 for the link object
that implements the first conversion function, and define the
Postgresql operator with the following syntax
CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so', 'mytype2_to_mytype3'
LANGUAGE 'C'
The syntax for the AS clause, which was 'AS <link-file>' becomes
AS <link_file>[, <link_name>]
Specification of the link_name is optional, and not needed if the link
name is the same as the Postgresql function name.
I store the string for the link symbol in the prosrc text attribute of
the pg_proc table which is currently unused in rows that reference
dynamically loaded functions.
Sounds like a good plan to me. I'll be glad to check this over and
commit it into 6.6 (unless there are objections?) ... but could I
trouble you for documentation diffs as well? At the very least,
the text discussion of CREATE FUNCTION, the reference page entry,
and the online help in psql need to reflect this addition.
regards, tom lane
From bouncefilter Mon Sep 13 21:33:49 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA94405
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 21:32:55 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id VAA06678;
Mon, 13 Sep 1999 21:03:04 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909140103.VAA06678@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <11056.937256188@sss.pgh.pa.us> from Tom Lane at "Sep 13,
1999 04:56:28 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 13 Sep 1999 21:03:04 -0400 (EDT)
CC: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
And I can't take credit for that either --- Hiroshi and/or Tatsuo get
the credit, IIRC. (BTW, did we patch those into 6.5.*, or only 6.6?)Update frontend libpq to remove limits on query lengths,
error/notice message lengths, and number of fields per tuple(Tom)This is *not* in 6.5.*, only 6.6.
I have:
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/pqexpbuffer.c,v
Working file: src/interfaces/libpq/pqexpbuffer.c
head: 1.1
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 1; selected revisions: 1
description:
----------------------------
revision 1.1
date: 1999/08/31 01:37:37; author: tgl; state: Exp;
Update frontend libpq to remove limits on query lengths,
error/notice message lengths, and number of fields per tuple. Add
pqexpbuffer.c/.h, a frontend version of backend's stringinfo module.
This is first step in applying Mike Ansley's long-query patches,
even though he didn't do any of these particular changes...
Seems addition of text files shows up in all branches, which I guess
makes sense. No cause for alarm.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Mon Sep 13 22:16:50 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 WAA00151
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 22:16: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 CAA22517;
Tue, 14 Sep 1999 02:11:53 GMT
Sender: lockhart@hub.org
Message-ID: <37DDAEE8.4A6C3982@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 02:11:52 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ansley, Michael" <Michael.Ansley@intec.co.za>
CC: Bruce Momjian <maillist@candle.pha.pa.us>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
References: <199909131630.MAA19046@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Maybe the core team should take a look at the TODO list, and split it over
the next couple of release cycles. Then you can just say, when a and b and
c have been achieved, and are stable, then we release 6.xI would be nice if we could do that, but people work as they have time
and interest in certain areas. Also, things get fixed as people find
problems and we become more capable with the source code.
I used to be more certain that at least a "notice of intent" for
future development would help the project. But very little of the
specific improvements and fixes over the last few releases were ones
we would have predicted would happen, and we certainly would not have
gotten the order right.
As Bruce points out, things just seem to happen. And one can't plan
for, for example, Tom Lane getting bit by the bug and becoming a major
contributor over the last few months. We've gotten very far (farther
than I would have imagined) by letting others come up with ideas for
improvements. The core group ain't as smart as you might think ;)
Though it drove me nuts earlier, resisting the temptation to cast into
concrete a short- or medium-range plan has been a real plus for the
project as a whole. We don't very often reject ideas which pass the
discussion phase, and people know that their ideas will make it into
the release cycle asap.
otoh, you might consider your suggestion as a "docs project", rather
than firm planning, and one could put some time into taking Bruce's
ToDo list, sorting it into topics, and writing up a more verbose
description for some of the topic areas. Just an idea...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Sep 13 22:27: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 WAA01538
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 22:27: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 CAA22558;
Tue, 14 Sep 1999 02:26:19 GMT
Sender: lockhart@hub.org
Message-ID: <37DDB24B.6B1193E@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 02:26:19 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
CC: "G. Anthony Reina" <reina@nsi.edu>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Is "isolation" a restricted word?
References: <37DD6E70.B27F2D80@nsi.edu>
<19990913164626.A32509@wallace.ece.rice.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
reason, I am getting a parser error:
=> create table cell ( isolation text );
ERROR: parser: parse error at or near "isolation"
This table had no problems previously; has the word isolation been used
somewhere else as a SQL word? I can't think of why else I am having
problems with the table (the syntax appears to be correct).Yup - here it is in pgsql/src/backend/parser/keywords.c:
This table should in fact be the definitive guide, since it's the array
that the parser uses ;-)
It is a definitive guide for keywords, but is a superset of keywords
which are allowed as column names. In this case, ISOLATION was added
to the syntax but was not added to gram.y as an allowed column id.
Edit src/backend/parser/gram.y, look for the line starting with
"ColId:", and add ISOLATION to the already long list of keywords which
follows.
I'll make the change for v6.6; it could perhaps be used for v6.5.3
also, if there is one.
And it's mentioned in the HISTORY file as part of the MVCC
changes. They're a couple of these 'gotcha' words that are part of
the SQL standard, but hadn't yet been implemented before 6.5 that have
tripped up people.
Keep reporting them, because in some cases we can allow them even
though they may be a reserved word in SQL92. But that can lead to
portability problems, not that I can imagine anyone moving away from
Postgres ;)
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Mon Sep 13 22:59:50 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 WAA05124
for <pgsql-hackers@postgreSQL.org>;
Mon, 13 Sep 1999 22:59:34 -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 CAA22583;
Tue, 14 Sep 1999 02:59:02 GMT
Sender: lockhart@hub.org
Message-ID: <37DDB9F5.9CCBF433@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 02:59:01 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
"G. Anthony Reina" <reina@nsi.edu>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Is "isolation" a restricted word?
References: <37DD6E70.B27F2D80@nsi.edu>
<19990913164626.A32509@wallace.ece.rice.edu>
<37DDB24B.6B1193E@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
This table had no problems previously; has the word isolation been used
somewhere else as a SQL word?And it's mentioned in the HISTORY file as part of the MVCC
changes. They're a couple of these 'gotcha' words that are part of
the SQL standard, but hadn't yet been implemented before 6.5 that have
tripped up people.
btw, it *is* documented as an SQL92 reserved word and a Postgres
reserved word in the big docs in the chapter on "Syntax".
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 14 03:45:53 1999
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA54411
for <hackers@postgresql.org>; Tue, 14 Sep 1999 03:44:55 -0400 (EDT)
(envelope-from andreas.zeugswetter@telecom.at)
Received: from telecom.at (w0188000580.f000.d0188.sd.spardat.at
[172.18.65.249])
by gandalf.telecom.at (xxx/xxx) with ESMTP id JAA166338
for <hackers@postgresql.org>; Tue, 14 Sep 1999 09:44:27 +0200
Message-ID: <37DDFCD9.41DB3DA7@telecom.at>
Date: Tue, 14 Sep 1999 09:44:25 +0200
From: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgresql.org
Subject: Re: [HACKERS] Patch for user-defined C-language functions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Postgresql operator with the following syntax
CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so', 'mytype2_to_mytype3'
LANGUAGE 'C'The syntax for the AS clause, which was 'AS <link-file>' becomes
AS <link_file>[, <link_name>]
Sounds great !
But I think the intuitive Syntax in SQL would use ():
CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so(mytype2_to_mytype3)'
LANGUAGE 'C'
Syntax:
AS <link_file>[(symbol_name)]
This is also how Illustra and now Informix does it.
(Instead of AS they say EXTERNAL NAME)
Andreas
From bouncefilter Tue Sep 14 04:03:54 1999
Received: from s-nath-exch1.nath-gpbry.co.za (mail.newaftech.com
[209.212.104.161]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA56481
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 04:03:44 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <S4RBA73F>; Tue, 14 Sep 1999 10:03:59 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C076@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Leon'" <leon@udmnet.ru>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: hackers <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Status report: long-query-string changes
Date: Tue, 14 Sep 1999 09:57:29 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
BTW, while eyeing the scan.l again, I noticed that C - style comments
can also contain bugs, but I am not completely sure.
What's your theory.
From bouncefilter Tue Sep 14 07:20:56 1999
Received: from flame.flame.co.za (flame.flame.co.za [160.124.170.1])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA81051
for <hackers@postgresql.org>; Tue, 14 Sep 1999 07:19:50 -0400 (EDT)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id NAA25904
for <hackers@postgresql.org>; Tue, 14 Sep 1999 13:22:28 +0200
Sender: theo@flame.flame.co.za
Message-ID: <37DE2FF4.AA093481@flame.co.za>
Date: Tue, 14 Sep 1999 13:22:28 +0200
From: Theo Kramer <theo@flame.co.za>
Organization: Flame Computing Enterprises
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgresql.org
Subject: ISO dates with European Format
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I have the requirement for ISO dates with European format and would
like to change backend/utils/adt/dt.c:EncodeDateTime() and EncodeDateOnly()
to effect this if this is a general requirement.
Please advise.
--
--------
Regards
Theo
From bouncefilter Tue Sep 14 07:47:56 1999
Received: from ns1.aktrad.ru (ns1.aktrad.ru [195.218.140.4])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA84082
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 07:47:09 -0400 (EDT) (envelope-from hook@aktrad.ru)
Received: from sloth (sloth.aktrad.ru [195.218.140.13])
by ns1.aktrad.ru (8.8.8/8.8.7) with SMTP id PAA20266;
Tue, 14 Sep 1999 15:44:27 +0400 (MSD) (envelope-from hook@aktrad.ru)
Message-ID: <043301befea6$7af511a0$0d8cdac3@aktrad.ru>
From: "Gene Sokolov" <hook@aktrad.ru>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
References: <6806.935767784@sss.pgh.pa.us>
Subject: Re: [HACKERS] Performance of MIN() and MAX()
Date: Tue, 14 Sep 1999 15:44:18 +0400
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211
From: Tom Lane <tgl@sss.pgh.pa.us>
I was under impression that when max(<primary key>) is called, it should
just take the value from the index. I believe it should not do any kind
of
scan. But, in fact, it scans the table.
You are mistaken. Postgres has no idea that min() and max() have any
semantics that have anything to do with indexes. I would like to see
that optimization myself, but it's not a particularly easy thing to add
given the system structure and the emphasis on datatype extensibility.it's a show stopper for us.
You might be able to hack around the issue with queries like
SELECT x FROM table ORDER BY x LIMIT 1;
SELECT x FROM table ORDER BY x DESC LIMIT 1;
It is a real show stopper. No luck completely, the indexes are ignored:
*************************************************************
[PostgreSQL 6.5.0 on i386-unknown-freebsd3.2, compiled by gcc 2.7.2.1]
bars=> create index bars_id on itemsbars(id);
CREATE
bars=> explain select id from itemsbars order by id limit 1;
NOTICE: QUERY PLAN:
Sort (cost=44404.41 rows=969073 width=4)
-> Seq Scan on itemsbars (cost=44404.41 rows=969073 width=4)
EXPLAIN
bars=> \d itemsbars
Table = itemsbars
+--------------------+----------------------------------+-------+
| Field | Type | Length|
+--------------------+----------------------------------+-------+
| id | int4 not null default nextval('" | 4 |
| itemid | int4 not null | 4 |
| interv | int4 not null | 4 |
| stats | datetime not null | 8 |
| endts | datetime not null | 8 |
| isactive | bool not null | 1 |
| opn | float8 not null | 8 |
| high | float8 not null | 8 |
| low | float8 not null | 8 |
| cls | float8 not null | 8 |
| vol | int4 not null | 4 |
+--------------------+----------------------------------+-------+
Indices: bars_complex2
bars_endts
bars_id
bars_interv
bars_itemid
bars_stats
itemsbars_pkeyFrom bouncefilter Tue Sep 14 08:53:57 1999
Received: from ritchie.wplus.net (relay.wplus.net [195.131.52.179])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA90897
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 08:53:39 -0400 (EDT)
(envelope-from dms@woland.wplus.net)
Received: from woland.wplus.net (woland.wplus.net [195.131.0.39])
by ritchie.wplus.net (8.9.1/8.9.1/wplus.2) with ESMTP id QAA17328
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 16:53:38 +0400 (MSK/MSD)
X-Real-To: pgsql-hackers@postgreSQL.org
Received: (from dms@localhost)
by woland.wplus.net (8.9.2/8.9.1/wplus.2) id QAA22896
for pgsql-hackers@postgreSQL.org; Tue, 14 Sep 1999 16:53:38 +0400 (MSD)
Message-ID: <XFMail.990914165336.dms@wplus.net>
X-Mailer: XFMail 1.3 [p0] on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Date: Tue, 14 Sep 1999 16:53:36 +0400 (MSD)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: pgsql-hackers@postgreSQL.org
Subject: Explicit direction of index using
How I can specify explicitly, wich index is need to be used in
select query?
---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...
From bouncefilter Tue Sep 14 09:41:57 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 JAA96354
for <hackers@postgreSQL.org>; Tue, 14 Sep 1999 09:41: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 NAA23539;
Tue, 14 Sep 1999 13:40:13 GMT
Sender: lockhart@hub.org
Message-ID: <37DE503C.3D99F4CA@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 13:40:12 +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: Theo Kramer <theo@flame.co.za>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] ISO dates with European Format
References: <37DE2FF4.AA093481@flame.co.za>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I have the requirement for ISO dates with European format and would
like to change backend/utils/adt/dt.c:EncodeDateTime() and EncodeDateOnly()
to effect this if this is a general requirement.
What is "ISO dates with European format"? Is it a combination of ISO
date output with European-style input (which I think can be done
already), or something else? afaik ISO-8601 is specific about
suggested formats, and makes no distinction between European and other
conventions. Can you give examples? TIA
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 14 09:43:57 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 JAA96573
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 09:43:32 -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 NAA23552;
Tue, 14 Sep 1999 13:42:58 GMT
Sender: lockhart@hub.org
Message-ID: <37DE50E1.A601C8EE@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 13:42:57 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Dmitry Samersoff <dms@wplus.net>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Explicit direction of index using
References: <XFMail.990914165336.dms@wplus.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
How I can specify explicitly, wich index is need to be used in
select query?
afaik, you can't. Indices are completely decoupled from the query
language, but are usually present in rdbms' as a db-specific
optimization.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 14 09:54:57 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA98215
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 09:54:37 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA15998;
Tue, 14 Sep 1999 09:53:52 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: "pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-reply-to: Your message of Mon, 13 Sep 1999 21:03:04 -0400 (EDT)
<199909140103.VAA06678@candle.pha.pa.us>
Date: Tue, 14 Sep 1999 09:53:52 -0400
Message-ID: <15996.937317232@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Bruce Momjian <maillist@candle.pha.pa.us> writes:
This is *not* in 6.5.*, only 6.6.
I have:
RCS file: /usr/local/cvsroot/pgsql/src/interfaces/libpq/pqexpbuffer.c,v
Working file: src/interfaces/libpq/pqexpbuffer.c
head: 1.1
Seems addition of text files shows up in all branches, which I guess
makes sense. No cause for alarm.
I've noticed that cvs log seems a little bogus in its handling of
branches, even though cvs status and cvs update know perfectly well
what belongs to the local branch and what doesn't. If you say
"cvs log" you get the "current" (tip revision's) log entries, even
if you are in a directory that's been checked out with a sticky
branch tag. If you say "cvs log -rBRANCH" you get the branch's
log entries, but *only* those applied since the branch was split;
there doesn't seem to be any way to get the full history as seen
in this branch. And, as above, it's quite confusing about files
that are not in the local branch at all.
Dunno if the cvs folk consider these behaviors bugs or features,
but they're definitely something to be wary of when working in
a branch...
regards, tom lane
From bouncefilter Tue Sep 14 10:00:58 1999
Received: from flame.flame.co.za (flame.flame.co.za [160.124.170.1])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA99232
for <hackers@postgreSQL.org>; Tue, 14 Sep 1999 10:00:42 -0400 (EDT)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id QAA26489;
Tue, 14 Sep 1999 16:03:17 +0200
Sender: theo@flame.flame.co.za
Message-ID: <37DE55A5.92E273DD@flame.co.za>
Date: Tue, 14 Sep 1999 16:03:17 +0200
From: Theo Kramer <theo@flame.co.za>
Organization: Flame Computing Enterprises
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] ISO dates with European Format
References: <37DE2FF4.AA093481@flame.co.za>
<37DE503C.3D99F4CA@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
I have the requirement for ISO dates with European format and would
like to change backend/utils/adt/dt.c:EncodeDateTime() and EncodeDateOnly()
to effect this if this is a general requirement.What is "ISO dates with European format"? Is it a combination of ISO
date output with European-style input (which I think can be done
already), or something else? afaik ISO-8601 is specific about
suggested formats, and makes no distinction between European and other
conventions. Can you give examples? TIA
Sure -
coza=> set datestyle to 'SQL,European';
SET VARIABLE
coza=> select registrationdate from accounts where domain = 'flame.co.za';
registrationdate
---------------------------
02/06/1997 00:00:00.00 SAST
(1 row)
The above result is correct for dd/mm/yyyy styles
coza=> set datestyle to 'ISO,European';
SET VARIABLE
coza=> select registrationdate from accounts where domain = 'flame.co.za';
registrationdate
----------------------
1997-06-02 00:00:00+02
(1 row)
Instead of 02-06-1997 00:00:00+02
If ISO is specific regarding formatting of days, month and year then I feel that
the "set datestyle to 'ISO,European'" should give an error. However, I would
personally
prefer it to format the result as "dd-mm-yyyy".
--------
Regards
Theo
From bouncefilter Tue Sep 14 10:21: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 KAA01806
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 10:21:41 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA23654;
Tue, 14 Sep 1999 14:16:46 GMT
Sender: lockhart@hub.org
Message-ID: <37DE58CE.CA64B35F@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 14:16:46 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] serial type
References: <14863.937065369@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
I am not sure if this is a mistake in the construction of the parsetree
(Thomas, what do you think?) or if the node print functions need to be
modified. I think it'd be easiest to alter the parsetree, though.
Perhaps the UNIQUE constraint ought to be attached somewhere else.
If I understand the problem correctly, the "column name" field in the
constraint clause attached to the column node is being used to look up
the column node, resulting in a recursive infinite loop. Or is
something else happening with direct pointers back to a parent node?
The CONSTR_UNIQUE node travels from gram.y to analyze.c attached to
the column node (it can also be specified as a table constraint, and
is attached elsewhere for that case). Within transformCreateStmt(), I
scan through these constraint nodes, filling in missing info, and
collecting them in a "deferred list" to look at later in the same
routine. I don't detach the constraint nodes from the column nodes at
that time, though it might be possible to do so.
Can you clarify the problem for me? I'm afraid that I didn't pay
enough attention to the thread :(
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 14 10:27:58 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA02362
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 10:27: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 KAA16227;
Tue, 14 Sep 1999 10:25:32 -0400 (EDT)
To: "Gene Sokolov" <hook@aktrad.ru>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Performance of MIN() and MAX()
In-reply-to: Your message of Tue, 14 Sep 1999 15:44:18 +0400
<043301befea6$7af511a0$0d8cdac3@aktrad.ru>
Date: Tue, 14 Sep 1999 10:25:32 -0400
Message-ID: <16225.937319132@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"Gene Sokolov" <hook@aktrad.ru> writes:
From: Tom Lane <tgl@sss.pgh.pa.us>
You might be able to hack around the issue with queries like
SELECT x FROM table ORDER BY x LIMIT 1;
SELECT x FROM table ORDER BY x DESC LIMIT 1;
It is a real show stopper. No luck completely, the indexes are ignored:
bars=> explain select id from itemsbars order by id limit 1;
NOTICE: QUERY PLAN:
Sort (cost=44404.41 rows=969073 width=4)
-> Seq Scan on itemsbars (cost=44404.41 rows=969073 width=4)
Yes, you missed my comment that 6.5.* needs some help or it won't
consider an index scan at all. This gives the right sort of plan:
regression=> explain select id from itemsbars where id > 0 order by id limit 1;
NOTICE: QUERY PLAN:
Index Scan using itemsbars_id_key on itemsbars (cost=21.67 rows=334 width=4)
The WHERE clause can be chosen so that it won't actually exclude
anything, but there has to be a WHERE clause that looks useful with
an index or an indexscan plan won't even get generated. (Also,
the DESC case doesn't work in 6.5.*, unless you apply the backwards-
index-scan patch that Hiroshi posted a few weeks ago.)
This is fixed in current sources, BTW:
regression=> explain select id from itemsbars order by id limit 1;
NOTICE: QUERY PLAN:
Index Scan using bars_id on itemsbars (cost=62.00 rows=1000 width=4)
regression=> explain select id from itemsbars order by id desc ;
NOTICE: QUERY PLAN:
Index Scan Backward using bars_id on itemsbars (cost=62.00 rows=1000 width=4)
although we still need to do some rejiggering of the cost estimation
rules; current sources are probably *too* eager to use an indexscan.
regards, tom lane
From bouncefilter Tue Sep 14 10:38: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 KAA03807
for <hackers@postgreSQL.org>; Tue, 14 Sep 1999 10:38:47 -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 OAA23687;
Tue, 14 Sep 1999 14:38:10 GMT
Sender: lockhart@hub.org
Message-ID: <37DE5DD1.97671019@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 14:38:09 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Theo Kramer <theo@flame.co.za>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] ISO dates with European Format
References: <37DE2FF4.AA093481@flame.co.za>
<37DE503C.3D99F4CA@alumni.caltech.edu>
<37DE55A5.92E273DD@flame.co.za>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
What is "ISO dates with European format"? Is it a combination of ISO
date output with European-style input (which I think can be done
already), or something else? afaik ISO-8601 is specific about
suggested formats, and makes no distinction between European and other
conventions. Can you give examples? TIAcoza=> set datestyle to 'SQL,European';
...
02/06/1997 00:00:00.00 SAST
The above result is correct for dd/mm/yyyy styles
coza=> set datestyle to 'ISO,European';
...
1997-06-02 00:00:00+02
Instead of 02-06-1997 00:00:00+02
If ISO is specific regarding formatting of days, month and year then I feel that
the "set datestyle to 'ISO,European'" should give an error. However, I would
personally prefer it to format the result as "dd-mm-yyyy".
Ah! The yyyy-mm-dd order is specified by ISO-8601. wrt Postgres, you
are actually wanting European format with "-" as a date delimiter,
rather than the "/".
As an aside, "ISO,European" does actually have meaning, since setting
the DateStyle to ISO only fully constrains the output format, but
"European" helps the date parser resolve free-form date input
ambiguities by assuming European, rather than US, conventions for
ordering of input fields.
But back to the delimiter...
Date conventions between and among countries vary. The formats we
currently have each meet the conventions of multiple countries (not
certain about "German", since apparently other Germanic countries do
not all share the same convention). There are (at least) two things we
could do:
1) Parameterize the delimiter field using a #define constant you can
redefine in Makefile.global, Makefile.custom, or configure. Apparently
South Africa uses the "-" convention for date delimiters? Or is this a
more local or project-specific preference??
2) Parameterize the delimiter as a global character variable, which
can be manipulated by something like "set DateDelimiter = '-'". This
is a little nervous-making for me, since you (and every database user)
would have the ability to modify the date format to something that
Postgres can not read. So we would have to modify the input routines
to accept an arbitrary delimiter, as well as the conventional
delimiters (both "-" and "/") already recognized. I suppose we could
put constraints on the "set DateDelimiter" values to help protect from
this...
You could also consider massaging the date format as it is displayed
by your app, since that would give you full control over the
appearance.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 14 10:42:58 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA04302
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 10:42:37 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA16323;
Tue, 14 Sep 1999 10:39:44 -0400 (EDT)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] serial type
In-reply-to: Your message of Tue, 14 Sep 1999 14:16:46 +0000
<37DE58CE.CA64B35F@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 10:39:44 -0400
Message-ID: <16320.937319984@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
I am not sure if this is a mistake in the construction of the parsetree
(Thomas, what do you think?) or if the node print functions need to be
modified. I think it'd be easiest to alter the parsetree, though.
Perhaps the UNIQUE constraint ought to be attached somewhere else.
If I understand the problem correctly, the "column name" field in the
constraint clause attached to the column node is being used to look up
the column node, resulting in a recursive infinite loop. Or is
something else happening with direct pointers back to a parent node?
The problem is with direct pointers in the parse tree: the column
node has a list of constraint nodes attached to it, and the UNIQUE
node in that list has a keys field that points at the column node.
The node print routines try to recurse through this structure, and
of course it's a never-ending recursion.
BTW, it's not only SERIAL that causes the problem; plain old
create table z2 (f1 int4 unique);
will crash the backend if you start psql with PGOPTIONS="-d5".
As I said, I'm not sure if the answer is to change the parsetree
representation, or to try to make node print/read smarter about
this looping structure. But I'd incline to the first --- the
looped structure puts all sorts of tree-traversal algorithms at
risk.
regards, tom lane
From bouncefilter Tue Sep 14 10:53:58 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA05678
for <hackers@postgreSQL.org>; Tue, 14 Sep 1999 10:53:54 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA16367;
Tue, 14 Sep 1999 10:53:09 -0400 (EDT)
To: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Patch for user-defined C-language functions
In-reply-to: Your message of Tue, 14 Sep 1999 09:44:25 +0200
<37DDFCD9.41DB3DA7@telecom.at>
Date: Tue, 14 Sep 1999 10:53:09 -0400
Message-ID: <16365.937320789@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Andreas Zeugswetter <andreas.zeugswetter@telecom.at> writes:
But I think the intuitive Syntax in SQL would use ():
CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so(mytype2_to_mytype3)'
LANGUAGE 'C'
Syntax:
AS <link_file>[(symbol_name)]
I think Bernard had the better solution --- the above presumes that
filenames won't ever have parens in them. (Which, admittedly, is a
bad idea under most Unix shells --- but that doesn't mean we should
perpetuate the problem.) Also, I'd rather see us keep the platform-
dependent ".so" extension at the end of its string, where it's easy
to spot and fix when needed.
regards, tom lane
From bouncefilter Tue Sep 14 10:59: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 KAA06485
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 10:59:35 -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 OAA23748;
Tue, 14 Sep 1999 14:58:30 GMT
Sender: lockhart@hub.org
Message-ID: <37DE6296.7E50B1AF@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 14:58:30 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Michael Simms <grim@argh.demon.co.uk>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] serial type
References: <16320.937319984@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The problem is with direct pointers in the parse tree: the column
node has a list of constraint nodes attached to it, and the UNIQUE
node in that list has a keys field that points at the column node.
The node print routines try to recurse through this structure, and
of course it's a never-ending recursion.
BTW, it's not only SERIAL that causes the problem; plain old
create table z2 (f1 int4 unique);
will crash the backend if you start psql with PGOPTIONS="-d5".
Sure. The same structure is used to represent column *and* table
constraints; in the table case there is a need to refer to a column
from within the structure since there is not explicit column context
from a parent to use.
btw, the following *does* work wrt printing the parse tree:
postgres=> create table tc (i int, unique(i));
NOTICE: CREATE TABLE/UNIQUE will create implicit index
'tc_i_key' for table 'tc'
CREATE
I suppose I could add code to explicitly unlink UNIQUE constraints
from the column-specific constraints, *or* we could change the
structure used for column constraints. I'd prefer mucking with the
parse tree as shipped from gram.y as little as possible, of course,
but your point about trouble lurking with recursive structures is well
taken.
Suggestions?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 14 11:21:59 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA11799
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 11:21:32 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA16481
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 11:21:00 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Status report: long-query-string changes
In-reply-to: Your message of Tue, 14 Sep 1999 02:11:52 +0000
<37DDAEE8.4A6C3982@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 11:21:00 -0400
Message-ID: <16479.937322460@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
Though it drove me nuts earlier, resisting the temptation to cast into
concrete a short- or medium-range plan has been a real plus for the
project as a whole.
The facts of the matter are that contributors work on the problems that
they find interesting, and/or the things that are getting in the way of
their own use of Postgres at the moment. If the core team tried to tell
people what to work on, less would get contributed, and that would
benefit no one.
When 6.5 was released, I tried to stir up a little discussion about the
major things to work on for 6.6, and couldn't even get any consensus
on a plan for *one* revision. So I think a longer-term plan would be
an exercise in wishful thinking. Things will get done when someone
steps up to the plate and does them.
otoh, you might consider your suggestion as a "docs project", rather
than firm planning, and one could put some time into taking Bruce's
ToDo list, sorting it into topics, and writing up a more verbose
description for some of the topic areas. Just an idea...
Indeed, the TODO list is awfully bare-bones; many of the entries don't
convey much information to someone who's not already familiar with the
issue. Something more fleshed-out would be a useful project.
regards, tom lane
From bouncefilter Tue Sep 14 11:25:59 1999
Received: from flame.flame.co.za (flame.flame.co.za [160.124.170.1])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA12474
for <hackers@postgreSQL.org>; Tue, 14 Sep 1999 11:25:45 -0400 (EDT)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id RAA26726;
Tue, 14 Sep 1999 17:28:21 +0200
Sender: theo@flame.flame.co.za
Message-ID: <37DE6995.81AD5DC0@flame.co.za>
Date: Tue, 14 Sep 1999 17:28:21 +0200
From: Theo Kramer <theo@flame.co.za>
Organization: Flame Computing Enterprises
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] ISO dates with European Format
References: <37DE2FF4.AA093481@flame.co.za>
<37DE503C.3D99F4CA@alumni.caltech.edu>
<37DE55A5.92E273DD@flame.co.za>
<37DE5DD1.97671019@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Ah! The yyyy-mm-dd order is specified by ISO-8601. wrt Postgres, you
are actually wanting European format with "-" as a date delimiter,
rather than the "/".
Yuck on ISO and yup to the rest :-).
As an aside, "ISO,European" does actually have meaning, since setting
the DateStyle to ISO only fully constrains the output format, but
"European" helps the date parser resolve free-form date input
ambiguities by assuming European, rather than US, conventions for
ordering of input fields.But back to the delimiter...
Date conventions between and among countries vary. The formats we
currently have each meet the conventions of multiple countries (not
certain about "German", since apparently other Germanic countries do
not all share the same convention). There are (at least) two things we
could do:1) Parameterize the delimiter field using a #define constant you can
redefine in Makefile.global, Makefile.custom, or configure. Apparently
South Africa uses the "-" convention for date delimiters? Or is this a
more local or project-specific preference??
Pretty much project related regarding the delimiter. We tend to use
dd/mm/yyyy locally. I would prefer to not create a specific postgres.
2) Parameterize the delimiter as a global character variable, which
can be manipulated by something like "set DateDelimiter = '-'". This
is a little nervous-making for me, since you (and every database user)
would have the ability to modify the date format to something that
Postgres can not read. So we would have to modify the input routines
to accept an arbitrary delimiter, as well as the conventional
delimiters (both "-" and "/") already recognized. I suppose we could
put constraints on the "set DateDelimiter" values to help protect from
this...
Hmmm, a product I helped develop uses two mechanisms for specifying
date style. First the format and second the picture. The format
allows swapping of sub fields within a date and a picture to specify
the output. Eg. dd/mm/yyyy as a format with a picture of 99/99/9999 or
mm/dd/yyyy and 99/99/9999 or dd-mmm-yyyy and 99-xxx-9999. This format
allows total control over dates (at least in Western countries) ... I
am happy to donate the code... Windows (int the regional settings) follows
a similar approach.
You could also consider massaging the date format as it is displayed
by your app, since that would give you full control over the
appearance.
True :-). Thanks for the responses.
--------
Regards
Theo
From bouncefilter Tue Sep 14 11:45: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 LAA15589
for <hackers@postgreSQL.org>; Tue, 14 Sep 1999 11:45: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 PAA23876;
Tue, 14 Sep 1999 15:44:25 GMT
Sender: lockhart@hub.org
Message-ID: <37DE6D59.C53E004C@alumni.caltech.edu>
Date: Tue, 14 Sep 1999 15:44:25 +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: Theo Kramer <theo@flame.co.za>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] ISO dates with European Format
References: <37DE2FF4.AA093481@flame.co.za>
<37DE503C.3D99F4CA@alumni.caltech.edu>
<37DE55A5.92E273DD@flame.co.za>
<37DE5DD1.97671019@alumni.caltech.edu>
<37DE6995.81AD5DC0@flame.co.za>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hmmm, a product I helped develop uses two mechanisms for specifying
date style. First the format and second the picture. The format
allows swapping of sub fields within a date and a picture to specify
the output. Eg. dd/mm/yyyy as a format with a picture of 99/99/9999 or
mm/dd/yyyy and 99/99/9999 or dd-mmm-yyyy and 99-xxx-9999. This format
allows total control over dates (at least in Western countries) ... I
am happy to donate the code... Windows (int the regional settings) follows
a similar approach.
Well, this sounds interesting even if Windows *does* use the same
technique ;)
Certainly contributing the code could be useful. It could make its way
into user contrib code, into special built-in formatting functions, or
possibly into the backend as the default formatting mechanism. Without
seeing the code and understanding the tradeoffs I can't predict which
would be the most suitable, though in any case user contributed code
is a great way to test out a new technique.
If you want, post it raw or package it as user contributed code;
either way, we'll look at it. TIA
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Tue Sep 14 11:24:59 1999
Received: from postal.dn.net (postal.dn.net [207.226.170.20])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA12093
for <hackers@postgreSQL.org>; Tue, 14 Sep 1999 11:24:36 -0400 (EDT)
(envelope-from frankpit@pop.dn.net)
Received: from pop.dn.net (pm-55.ppp.wdc.dn.net [207.226.188.55])
by postal.dn.net (8.9.3/postal) with ESMTP id LAA10180;
Tue, 14 Sep 1999 11:23:57 -0400 (EDT)
Sender: matuser@postal.dn.net
Message-ID: <37DE6E02.32E4B3AD@pop.dn.net>
Date: Tue, 14 Sep 1999 15:47:14 +0000
From: Bernard Frankpitt <frankpit@pop.dn.net>
Organization: AIMS
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.32 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Andreas Zeugswetter <andreas.zeugswetter@telecom.at>,
hackers@postgreSQL.org
Subject: Re: [HACKERS] Patch for user-defined C-language functions
References: <37DDFCD9.41DB3DA7@telecom.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Andreas Zeugswetter wrote:
But I think the intuitive Syntax in SQL would use ():
CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so(mytype2_to_mytype3)'
LANGUAGE 'C'Syntax:
AS <link_file>[(symbol_name)]This is also how Illustra and now Informix does it.
(Instead of AS they say EXTERNAL NAME)
The syntax
AS <link_file>[(symbol_name)]
would be easy to implement provided I could write your example as
CREATE FUNCTION mytype3 ( mytype2 )
RETURNS mytype3
AS 'mytypes.so'('mytype2_to_mytype3')
LANGUAGE 'C'
That way link_file and symbol_name both look like string tokens to
the parser. If it is implemented the way you write in the example with
'mytypes.so(mytype2_to_mytype3)'
Then the parser sees the arguement of the AS clause as a single
string token which would have to be parsed separately. Also, there is
some ambiguity in this form as to whether the string
'mytypes.so(mytype2_to_mytype3)'
is a single filename, or a filename and a link symbol
Bernie
From bouncefilter Tue Sep 14 14:17:01 1999
Received: from mail_dns.lagoon.nc (mail.offratel.nc [209.58.55.28])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA36035;
Tue, 14 Sep 1999 14:16:07 -0400 (EDT)
(envelope-from fillons@offratel.nc)
Received: from portable (unverified [209.58.55.166]) by mail_dns.lagoon.nc
(Rockliffe SMTPRA 3.4.3) with SMTP id <B0000057636@mail_dns.lagoon.nc>;
Wed, 15 Sep 1999 05:16:57 +1100
Message-ID: <000e01befedd$3e2210c0$a6373ad1@portable>
From: "=?iso-8859-1?Q?St=E9phane_FILLON?=" <fillons@offratel.nc>
To: "pgsql-sql" <pgsql-sql@postgresql.org>,
"pgsql-hackers" <pgsql-hackers@postgresql.org>,
"pgsql-general" <pgsql-general@postgresql.org>
Subject: Permission problem with COPY FROM
Date: Wed, 15 Sep 1999 03:50:09 +1100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_0004_01BEFF2D.684ADB20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
This is a multi-part message in MIME format.
------=_NextPart_000_0004_01BEFF2D.684ADB20
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
Each time I try to insert an ascii file with the COPY FROM command, I =
get the following message:
"ERROR: COPY command, running in backend with effective uid 501 (that's =
Postgres), could not open file '/usr/local/.../cltclr001' for reading. =
Error: Permission not allowed (13)."
What rights do I have to put to process the COPY command inside PSQL.
I have try nearly everything, actual rights: uog+rw even on the =
directory.
What's wrong.
Stephane FILLON
------=_NextPart_000_0004_01BEFF2D.684ADB20
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hi,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>Each time I try to insert an ascii =
file with the=20
COPY FROM command, I get the following message:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> "ERROR: COPY command, =
running in=20
backend with effective uid 501 (that's Postgres), could not open file=20
'/usr/local/.../cltclr001' for reading. Error: Permission not allowed=20
(13)."</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>What rights do I have to put to =
process the COPY=20
command inside PSQL.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>I have try nearly everything, actual =
rights:=20
uog+rw even on the directory.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>What's wrong.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Stephane FILLON</FONT></DIV></BODY></HTML>
------=_NextPart_000_0004_01BEFF2D.684ADB20--
From bouncefilter Tue Sep 14 13:07:05 1999
Received: from flame.flame.co.za (flame.flame.co.za [160.124.170.1])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA26872
for <hackers@postgreSQL.org>; Tue, 14 Sep 1999 13:06:05 -0400 (EDT)
(envelope-from theo@flame.co.za)
Received: from flame.co.za (flame [160.124.170.1])
by flame.flame.co.za (8.8.7/8.8.7) with ESMTP id TAA26924
for <hackers@postgreSQL.org>; Tue, 14 Sep 1999 19:08:52 +0200
Sender: theo@flame.flame.co.za
Message-ID: <37DE8123.FD2111AC@flame.co.za>
Date: Tue, 14 Sep 1999 19:08:51 +0200
From: Theo Kramer <theo@flame.co.za>
Organization: Flame Computing Enterprises
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.0.35 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: hackers@postgreSQL.org
Subject: Re: [HACKERS] ISO dates with European Format
References: <37DE2FF4.AA093481@flame.co.za>
<37DE503C.3D99F4CA@alumni.caltech.edu>
<37DE55A5.92E273DD@flame.co.za>
<37DE5DD1.97671019@alumni.caltech.edu>
<37DE6995.81AD5DC0@flame.co.za>
<37DE6D59.C53E004C@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
Well, this sounds interesting even if Windows *does* use the same
technique ;)Certainly contributing the code could be useful. It could make its way
into user contrib code, into special built-in formatting functions, or
possibly into the backend as the default formatting mechanism. Without
seeing the code and understanding the tradeoffs I can't predict which
would be the most suitable, though in any case user contributed code
is a great way to test out a new technique.If you want, post it raw or package it as user contributed code;
either way, we'll look at it. TIA
I'll rip it out, repackage it for postgres and send it off within the
next week.
--------
Regards
Theo
From bouncefilter Tue Sep 14 14:17:01 1999
Received: from mail_dns.lagoon.nc (mail.offratel.nc [209.58.55.28])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA36045;
Tue, 14 Sep 1999 14:16:13 -0400 (EDT)
(envelope-from fillons@offratel.nc)
Received: from portable (unverified [209.58.55.166]) by mail_dns.lagoon.nc
(Rockliffe SMTPRA 3.4.3) with SMTP id <B0000057637@mail_dns.lagoon.nc>;
Wed, 15 Sep 1999 05:17:00 +1100
Message-ID: <000f01befedd$3f26fda0$a6373ad1@portable>
From: "=?iso-8859-1?Q?St=E9phane_FILLON?=" <fillons@offratel.nc>
To: "pgsql-sql" <pgsql-sql@postgresql.org>,
"pgsql-hackers" <pgsql-hackers@postgresql.org>,
"pgsql-general" <pgsql-general@postgresql.org>
Subject: BUG with UNIQUE clause
Date: Wed, 15 Sep 1999 05:14:15 +1100
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_000B_01BEFF39.27AFBD40"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
This is a multi-part message in MIME format.
------=_NextPart_000_000B_01BEFF39.27AFBD40
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi,
The UNIQUE constraint doesn't work on a field if I use a DEFAULT clause =
on a table.
The following table works with UNIQUE constraint:
create table cltclt001(
tcid int2,
tcnom text unique
);
but this one accept several same tcnom value:
create table cltclt001(
tcid int2 default nextval('cltcls001'),
tcnom text unique
);
What's wrong with my table ?
Thanks in advance.
Stephane FILLON
------=_NextPart_000_000B_01BEFF39.27AFBD40
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>Hi,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The UNIQUE constraint doesn't work =
on a field if=20
I use a DEFAULT clause on a table.</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>The following table works with =
UNIQUE=20
constraint:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>create table cltclt001(</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2> tcid int2,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2> tcnom text =
unique</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>);</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>but this one accept several same =
tcnom=20
value:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>create table cltclt001(</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2> tcid int2 default=20
nextval('cltcls001'),</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2> tcnom text =
unique</FONT></DIV>
<DIV><FONT size=3D2>);</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>What's wrong with my table ?</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Thanks in advance.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2>Stephane FILLON</FONT></DIV></BODY></HTML>
------=_NextPart_000_000B_01BEFF39.27AFBD40--
From bouncefilter Tue Sep 14 18:46:04 1999
Received: from excelsior.rkirkpat.net (dhcp-210-85.letu.edu [204.158.210.85])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA72440
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 18:45:30 -0400 (EDT)
(envelope-from rkirkpat@rkirkpat.net)
Received: from localhost (rkirkpat@localhost)
by excelsior.rkirkpat.net (8.9.3/8.9.3/Debian/GNU) with ESMTP id
QAA26737; Tue, 14 Sep 1999 16:44:30 -0500
X-Authentication-Warning: excelsior.rkirkpat.net: rkirkpat owned process doing
-bs
Date: Tue, 14 Sep 1999 16:44:30 -0500 (CDT)
From: Ryan Kirkpatrick <rkirkpat@rkirkpat.net>
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Bruce Momjian <maillist@candle.pha.pa.us>,
Oleg Bartunov <oleg@sai.msu.su>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
In-Reply-To: <99091314130500.00567@lowen.wgcr.org>
Message-ID: <Pine.LNX.4.10.9909141642130.29674-100000@excelsior.rkirkpat.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 13 Sep 1999, Lamar Owen wrote:
Our problem is that minor releases don't get the same cross-platform
testing as major releases.I understand -- I am patch-munging as I write this, after booting into RedHat 6
on my notebook. If Ryan K is still around, he may find it easier going, as he
did the backpatch to 6.5.1. There are a couple of failed hunks, and some
reverses. We'll see how it goes.
Yea, I am still around, though a bit busy with school at the
moment. I should be able to get 6.5.2beta downloaded and the alpha patches
updated for it by Monday if you want me to try. Or, if you get an updated
alpha patch before then, email it to me, and I will try it out. TTYL.
---------------------------------------------------------------------------
| "For to me to live is Christ, and to die is gain." |
| --- Philippians 1:21 (KJV) |
---------------------------------------------------------------------------
| Ryan Kirkpatrick | Boulder, Colorado | http://www.rkirkpat.net/ |
---------------------------------------------------------------------------
From bouncefilter Tue Sep 14 18:19:03 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA69283
for <pgsql-hackers@postgreSQL.org>;
Tue, 14 Sep 1999 18:18:06 -0400 (EDT)
(envelope-from lamar.owen@wgcr.org)
Received: from lowen.wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id SAA04856;
Tue, 14 Sep 1999 18:17:43 -0400
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Ryan Kirkpatrick <rkirkpat@rkirkpat.net>
Subject: Re: [HACKERS] Re: HISTORY for 6.5.2
Date: Tue, 14 Sep 1999 18:11:58 -0400
X-Mailer: KMail [version 1.0.24]
Content-Type: text/plain
Cc: Bruce Momjian <maillist@candle.pha.pa.us>,
Oleg Bartunov <oleg@sai.msu.su>,
"pgsql-hackers@postgreSQL.org" <pgsql-hackers@postgreSQL.org>
References: <Pine.LNX.4.10.9909141642130.29674-100000@excelsior.rkirkpat.net>
MIME-Version: 1.0
Message-Id: <99091418173200.00623@lowen.wgcr.org>
Content-Transfer-Encoding: 8bit
On Tue, 14 Sep 1999, Ryan Kirkpatrick wrote:
Yea, I am still around, though a bit busy with school at the
moment. I should be able to get 6.5.2beta downloaded and the alpha patches
updated for it by Monday if you want me to try. Or, if you get an updated
alpha patch before then, email it to me, and I will try it out. TTYL.
You know that code far better than I; if you have time, applying those patches
to the final 6.5.2 would be a nice thing. I'm applying my time to getting RPM
upgrading working -- many thanks to Oliver Elphick for the Debian upgrade
scripts, some of which are very useful even in an RPM context.
Those 6.5.1 patches made alot of people very happy -- the guys at RedHat in
particular. Bravo to Uncle George for them originally, and bravo to you for
the backpatch and packaging to 6.5.1! Those patches, incidentally, will ship
with RedHat 6.1, if nothing happens between now and release time.
TIA!
Lamar Owen
WGCR Internet Radio
From bouncefilter Tue Sep 14 18:37:04 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id SAA71460
for pgsql-hackers@postgresql.org; Tue, 14 Sep 1999 18:36:06 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: "John Henry" <troy@teenpornsluts.com>
X-Newsgroups: comp.databases.postgresql.hackers
Subject: - WANTED
Date: Wed, 15 Sep 1999 08:32:15 +1000
Lines: 10
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Message-ID: <37decc80@news.ausmail.com>
X-Trace: 15 Sep 1999 08:30:24 +1000, 203.24.22.190
To: pgsql-hackers@postgresql.org
Hi im surfing the net to try and find someone who can help me. A friend of
mine told me that there are some people who know how to get sites listed at
the top of the search engines. I run an adult website am willing to pay
someone who can do this.
From bouncefilter Tue Sep 14 21:38:06 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id VAA94929
for pgsql-hackers@postgresql.org; Tue, 14 Sep 1999 21:37:50 -0400 (EDT)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: "Damond Walker" <dwalker@iximd.com>
X-Newsgroups: comp.databases.postgresql.hackers
References: <16225.937319132@sss.pgh.pa.us>
Subject: Re: [HACKERS] Performance of MIN() and MAX()
Lines: 33
X-Newsreader: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Message-ID: <zOCD3.37$3a1.10837@typhoon2.gnilink.net>
Date: Wed, 15 Sep 1999 01:40:47 GMT
X-Trace: typhoon2.gnilink.net 937359647 151.196.99.113 (Tue,
14 Sep 1999 21:40:47 EDT)
To: pgsql-hackers@postgresql.org
Tom Lane wrote in message <16225.937319132@sss.pgh.pa.us>...
although we still need to do some rejiggering of the cost estimation
rules; current sources are probably *too* eager to use an indexscan.
I did some testing today on a 1.6 million row table of random integers
in the range of 0..32767. Using explain I could get a "select max(f1)..."
down to a cost of about 30000 using a where clause of "f1 > 0"...
After running the queries I achieved the following results (dual P133,
w/ 128 megs ram, IDE)...
select max(f1) from t1 [68 seconds] [explain cost 60644.00]
select max(f1) from t1 where f1 > 0 [148 seconds] [explain cost
30416.67]
Knowing my data does have at least one value above 30000 I can apply a
better heuristic other than f1 > 0
select max(f1) from t1 where f1 > 30000 [12.43 seconds] [explain cost
30416.67]
Until more agg. function optimizations are implemented, programmers
might have to use the old melon to speed things up.
Damond
From bouncefilter Tue Sep 14 21:54:06 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 VAA96589
for <pgsql-general@postgreSQL.org>;
Tue, 14 Sep 1999 21:53:30 -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 BAA24518;
Wed, 15 Sep 1999 01:52:43 GMT
Sender: lockhart@hub.org
Message-ID: <37DEFBEB.8D75D0FB@alumni.caltech.edu>
Date: Wed, 15 Sep 1999 01:52: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: =?iso-8859-1?Q?St=E9phane?= FILLON <fillons@offratel.nc>
CC: pgsql-general <pgsql-general@postgreSQL.org>
Subject: Re: [HACKERS] BUG with UNIQUE clause
References: <000f01befedd$3f26fda0$a6373ad1@portable>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
The UNIQUE constraint doesn't work on a field if I use a DEFAULT
clause on a table.
The following table works with UNIQUE constraint:
but this one accept several same tcnom value:
create table cltclt001(
tcid int2 default nextval('cltcls001'),
tcnom text unique
);
What's wrong with my table ?
Nothing. You have stumbled across a bug recently discovered by Mark
Dalphin <mdalphin@amgen.com> in the parser. It was repaired in the
source trees 1999-08-15 so will appear in v6.5.2 (any day now) and
v6.6.
postgres=> create sequence cltcls001;
CREATE
postgres=> insert into cltclt001 (tcnom) values ('one');
INSERT 150559 1
postgres=> insert into cltclt001 (tcnom) values ('one');
ERROR: Cannot insert a duplicate key into a unique index
I imagine that the repair is posted to the patches or hacker's mailing
list; look in the archives around that date and you should be able to
patch your existing recent system.
Good luck.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Wed Sep 15 00:23:08 1999
Received: from johann.inet.co.th (nuchk@johann.inet.co.th [203.150.17.140])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA16631;
Wed, 15 Sep 1999 00:22:13 -0400 (EDT)
(envelope-from nuchk@inet.co.th)
Received: from localhost (nuchk@localhost)
by johann.inet.co.th (8.9.0/8.9.0) with ESMTP id LAA04233;
Wed, 15 Sep 1999 11:21:49 +0700 (GMT+0700)
X-Authentication-Warning: johann.inet.co.th: nuchk owned process doing -bs
Date: Wed, 15 Sep 1999 11:21:48 +0700 (GMT+0700)
From: Nuchanach Klinjun <nuchk@inet.co.th>
To: =?iso-8859-1?Q?St=E9phane_FILLON?= <fillons@offratel.nc>
cc: pgsql-sql <pgsql-sql@postgreSQL.org>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>,
pgsql-general <pgsql-general@postgreSQL.org>
Subject: Re: [HACKERS] Permission problem with COPY FROM
In-Reply-To: <000e01befedd$3e2210c0$a6373ad1@portable>
Message-ID: <Pine.OSF.4.10.9909151118490.1360-100000@johann.inet.co.th>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.org id AAB16676
Hi,
I've faced that problem too, then I use '\copy' instread
of 'copy' because 'copy' command will asked for super user previlege.
example
^^^^^^ -> \copy '/your location/your filename' to tablename;
Cheers,
On Wed, 15 Sep 1999, [iso-8859-1] St�phane FILLON wrote:
Hi,
Each time I try to insert an ascii file with the COPY FROM command, I get the following message:
"ERROR: COPY command, running in backend with effective uid 501 (that's Postgres), could not open file '/usr/local/.../cltclr001' for reading. Error: Permission not allowed (13)."
What rights do I have to put to process the COPY command inside PSQL.
I have try nearly everything, actual rights: uog+rw even on the directory.
What's wrong.
Stephane FILLON
-----------------------------------------
Nuchanach Klinjun
R&D Project. Internet Thailand
Email: nuchk@inet.co.th
From bouncefilter Wed Sep 15 00:28:09 1999
Received: from johann.inet.co.th (nuchk@johann.inet.co.th [203.150.17.140])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA17399
for <pgsql-hackers@postgreSQL.org>;
Wed, 15 Sep 1999 00:27:34 -0400 (EDT)
(envelope-from nuchk@inet.co.th)
Received: from localhost (nuchk@localhost)
by johann.inet.co.th (8.9.0/8.9.0) with ESMTP id LAA05035
for <pgsql-hackers@postgreSQL.org>;
Wed, 15 Sep 1999 11:27:28 +0700 (GMT+0700)
X-Authentication-Warning: johann.inet.co.th: nuchk owned process doing -bs
Date: Wed, 15 Sep 1999 11:27:28 +0700 (GMT+0700)
From: Nuchanach Klinjun <nuchk@inet.co.th>
To: pgsql-hackers@postgreSQL.org
Subject: problem with SQLGetInfo
Message-ID: <Pine.OSF.4.10.9909141648470.18748-100000@johann.inet.co.th>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Dear Sir,
I had some problem with configured the ODBC. I worked on MS Access97 and
ASP as frontend and use database on Postgres via ODBC. It used to work well
til the Postgres Db was upgraded to 6.5.1 version. Now,I use Postodbc
6.40.0007. ^^^^^^
^^^^^^^^^^
The error message which I got from psqlodbc.log is
conn=97458576, SQLDriverConnect( in)='DSN=access2; UID=nuchk;
PWD=araigodai;', fDriverCompletion=0
DSN info:
DSN='access2',server='myserver.co.th',port='5432',dbase='mydb',user='myname',passwd='mypass'
readonly='1',protocol='6.4',showoid='0',fakeoidindex='0',showsystable='0'
conn_settings=''
translation_dll='',translation_option=''
Global Options: Version='06.40.0007', fetch=100, socket=4096,
unknown_sizes=0, max_varchar_size=254, max_longvarchar_size=8190
disable_optimizer=1, ksqo=1, unique_index=0,
use_declarefetch=0
text_as_longvarchar=1, unknowns_as_longvarchar=0,
bools_as_char=1
extra_systable_prefixes='dd_;', conn_settings=''
conn=97458576, query=' '
conn=97458576, query='set DateStyle to 'ISO''
conn=97458576, query='set geqo to 'OFF''
conn=97458576, query='set ksqo to 'ON''
conn=97458576, query='select oid from pg_type where typname='lo''
[ fetched 0 rows ]
conn=97458576,
SQLDriverConnect(out)='DSN=access2;DATABASE=access;SERVER=safari.inet.co.th;PORT=5432;UID=nuchk;PWD=araigodai;READONLY=1;PROTOCOL=6.4;FAKEOIDINDEX=0;SHOWOIDCOLUMN=0;ROWVERSIONING=0;SHOWSYSTEMTABLES=0;CONNSETTINGS='
CONN ERROR: func=SQLGetInfo, desc='', errnum=209, errmsg='Unrecognized key passed to SQLGetInfo.'
------------------------------------------------------------
henv=97453632, conn=97458576, status=1, num_stmts=16
sock=97453648, stmts=97453696, lobj_type=-999
---------------- Socket Info -------------------------------
socket=2948, reverse=0, errornumber=0, errormsg='(null)'
buffer_in=97464912, buffer_out=97469016
buffer_filled_in=33, buffer_filled_out=0, buffer_read_in=32
I've tried so many times both re-install the previos version and
psqlodbc.dll and re-config it again follow the instruction which I
retrieved from postgres.org website.
I'm always got this error 'Unrecognized key passed to SQLGetInfo.'
what's the key I have to send? please help.
Hope to hear from you all soon.
Thanx,
Nuch
-----------------------------------------
Nuchanach Klinjun
R&D Project. Internet Thailand
Email: nuchk@inet.co.th
From bouncefilter Wed Sep 15 00:54:08 1999
Received: from web126.yahoomail.com (web126.yahoomail.com [205.180.60.195])
by hub.org (8.9.3/8.9.3) with SMTP id AAA20430
for <pgsql-hackers@postgresql.org>;
Wed, 15 Sep 1999 00:53:20 -0400 (EDT)
(envelope-from mascarim@yahoo.com)
Message-ID: <19990915045443.25169.rocketmail@web126.yahoomail.com>
Received: from [206.246.185.100] by web126.yahoomail.com;
Tue, 14 Sep 1999 21:54:43 PDT
Date: Tue, 14 Sep 1999 21:54:43 -0700 (PDT)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] Status report: long-query-string changes
To: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
--- Tom Lane <tgl@sss.pgh.pa.us> wrote:Thomas Lockhart <lockhart@alumni.caltech.edu>
writes:Though it drove me nuts earlier, resisting the
temptation to cast into
concrete a short- or medium-range plan has been a
real plus for the
project as a whole.
The facts of the matter are that contributors work
on the problems that
they find interesting, and/or the things that are
getting in the way of
their own use of Postgres at the moment.
....
Indeed, the TODO list is awfully bare-bones; many of
the entries don't
convey much information to someone who's not already
familiar with the
issue. Something more fleshed-out would be a useful
project.regards, tom lane
From someone who lurks in this list to see what's
upcoming in future releases, I have a couple of
comments (which may be politically incorrect):
1. The TODO list shows under ENHANCEMENTS as URGENT as
the number one item referential integrity. This is
something we need desperately. And since refint.c
with MVCC requires recoding our application (which is
composed of 115 C++ objects -- and those are just the
database related ones), we've been looking forward
to integrated referential integrity. Particularly
since refint.c is broke for cascading updates (it
saves
the SPI plan). The TODO list shows Jan as having
claimed this item -- perhaps he goes away working like
mad and comes back with a fantastic feature, like the
rules system -- but I haven't seen any posts by Jan
in months.
2. How is it that Tom Lane isn't considered "core"?
Sorry to stir the pot...but I was just curious,
Mike Mascari
(mascarim@yahoo.com)
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
From bouncefilter Wed Sep 15 01:47:09 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 BAA25206
for <pgsql-hackers@postgresql.org>;
Wed, 15 Sep 1999 01:46:25 -0400 (EDT) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id NAA21110;
Wed, 15 Sep 1999 13:46:17 +0800 (KRSS)
Sender: root@sunpine.krs.ru
Message-ID: <37DF32A7.62499F71@krs.ru>
Date: Wed, 15 Sep 1999 13:46:15 +0800
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Mike Mascari <mascarim@yahoo.com>
CC: pgsql-hackers@postgresql.org, Jan Wieck <jwieck@debis.com>
Subject: 6.6
References: <19990915045443.25169.rocketmail@web126.yahoomail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mike Mascari wrote:
1. The TODO list shows under ENHANCEMENTS as URGENT as
the number one item referential integrity. This is
something we need desperately. And since refint.c
with MVCC requires recoding our application (which is
composed of 115 C++ objects -- and those are just the
database related ones), we've been looking forward
to integrated referential integrity. Particularly
since refint.c is broke for cascading updates (it
saves the SPI plan). The TODO list shows Jan as having
claimed this item -- perhaps he goes away working like
mad and comes back with a fantastic feature, like the
rules system -- but I haven't seen any posts by Jan
in months.
I would like to see something from Jan too...
My opinion is that RI _MUST_ be implemented in 6.6.
There are 3 ways:
1. Using deferrable rules/statement level triggers.
2. Using transaction log (to read changes made in
parent/child tables and check RI constraints).
3. Using DIRTY READ in refint.c
I hope to be able to do 2. or 3., though it would be much
better to have 1. (with statement level triggers) implemented by Jan.
Vadim
From bouncefilter Wed Sep 15 09:48:14 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA74437;
Wed, 15 Sep 1999 09:47: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 JAA19037;
Wed, 15 Sep 1999 09:46:35 -0400 (EDT)
To: "=?iso-8859-1?Q?St=E9phane_FILLON?=" <fillons@offratel.nc>
cc: "pgsql-sql" <pgsql-sql@postgreSQL.org>,
"pgsql-hackers" <pgsql-hackers@postgreSQL.org>,
"pgsql-general" <pgsql-general@postgreSQL.org>
Subject: Re: [HACKERS] BUG with UNIQUE clause
In-reply-to: Your message of Wed, 15 Sep 1999 05:14:15 +1100
<000f01befedd$3f26fda0$a6373ad1@portable>
Date: Wed, 15 Sep 1999 09:46:35 -0400
Message-ID: <19035.937403195@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
"=?iso-8859-1?Q?St=E9phane_FILLON?=" <fillons@offratel.nc> writes:
The UNIQUE constraint doesn't work on a field if I use a DEFAULT clause
on a table.
This sounds closely related to a fix that Thomas Lockhart just made.
IIRC the complained-of symptom was that PRIMARY KEY on one column plus
UNIQUE on another didn't work, but the real problem was that PRIMARY
KEY implies UNIQUE and the table declaration code was getting confused
by two different UNIQUE columns in one table. It could be that his fix
addresses your problem too. Check the pghackers archives for the
last couple weeks to find the patch.
regards, tom lane
From bouncefilter Wed Sep 15 10:02:14 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA76341;
Wed, 15 Sep 1999 10:01: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 KAA19100;
Wed, 15 Sep 1999 10:00:02 -0400 (EDT)
To: Nuchanach Klinjun <nuchk@inet.co.th>
cc: =?iso-8859-1?Q?St=E9phane_FILLON?= <fillons@offratel.nc>,
pgsql-sql <pgsql-sql@postgreSQL.org>,
pgsql-hackers <pgsql-hackers@postgreSQL.org>,
pgsql-general <pgsql-general@postgreSQL.org>
Subject: Re: [HACKERS] Permission problem with COPY FROM
In-reply-to: Your message of Wed, 15 Sep 1999 11:21:48 +0700 (GMT+0700)
<Pine.OSF.4.10.9909151118490.1360-100000@johann.inet.co.th>
Date: Wed, 15 Sep 1999 10:00:02 -0400
Message-ID: <19098.937404002@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Nuchanach Klinjun <nuchk@inet.co.th> writes:
I've faced that problem too, then I use '\copy' instread
of 'copy' because 'copy' command will asked for super user previlege.
example
^^^^^^ -> \copy '/your location/your filename' to tablename;
It's not that; the error message Stephane quotes is after the
Postgres superuser-privilege check:
"ERROR: COPY command, running in backend with effective uid 501
(that's Postgres), could not open file '/usr/local/.../cltclr001' for
reading. Error: Permission not allowed (13)."
This is a result of the Unix kernel denying read access to the file.
It's got to be a matter of not having read rights on the file or not
having lookup (x) rights on one of the directories above it.
psql's \copy is often a better choice than the regular SQL COPY command,
though. It reads or writes the file with the privileges of the user
running psql, rather than those of the Postgres server, which is usually
a Good Thing. Also, if you are contacting a server on a different
machine, \copy works with files in the local filesystem, not the
server's filesystem.
regards, tom lane
From bouncefilter Wed Sep 15 10:03:14 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA76472
for <pgsql-hackers@postgresql.org>;
Wed, 15 Sep 1999 10:02: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 KAA19121;
Wed, 15 Sep 1999 10:02:07 -0400 (EDT)
To: Mike Mascari <mascarim@yahoo.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Status report: long-query-string changes
In-reply-to: Your message of Tue, 14 Sep 1999 21:54:43 -0700 (PDT)
<19990915045443.25169.rocketmail@web126.yahoomail.com>
Date: Wed, 15 Sep 1999 10:02:07 -0400
Message-ID: <19119.937404127@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Mike Mascari <mascarim@yahoo.com> writes:
2. How is it that Tom Lane isn't considered "core"?
The core guys have been here a lot longer. I've only been
working with Postgres for a year or so.
There are quite a few major contributors besides the core four,
actually.
regards, tom lane
Import Notes
Reference msg id not found: 37D69D22.8876C0C4@wgcr.org