Problems in 6.5.3 with Multi-Byte encoding

I have another kind of problem related with MB and 6.5.3.

On FreeBSD 3.1:

nature=> select u_address from users;
u_address
------------------------------
О©╫О©╫О©╫О©╫О©╫О©╫, О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫О©╫ О©╫О©╫. 13
(1 row)

nature=> set client_encoding to 'WIN';
SET VARIABLE
nature=> select u_address from users;
u_address
------------------------------
mOSKWA, uNIWERSITETSKIJ PR. 13
(1 row)

It seems that 8-bit was stripped !
I've checked locale on this machine - it works.

Moreover, 8-bit stripped even if I do silly setting of client_encoding
to native encoding:

ature=> set client_encoding to 'KOI8';
SET VARIABLE
nature=> select u_address from users;
u_address
------------------------------
mOSKWA, uNIWERSITETSKIJ PR. 13
(1 row)

It's interesting that on Linux I have no problem.
I have no time right now to test 6.5.2 but I recall I had no
such problem (not 100% sure).

Regards,
Oleg

On Fri, 19 Nov 1999, Oliver Elphick wrote:

Date: Fri, 19 Nov 1999 10:19:49 +0000
From: Oliver Elphick <olly@lfix.co.uk>
To: pgsql-bugs@postgresql.org, pgsql-hackers@postgresql.org
Cc: 50388@bugs.debian.org
Subject: [BUGS] Problems in 6.5.3 with Multi-Byte encoding

With PostgreSQL compiled with support for locales and multi-byte encoding:

initdb -e BIG5

[start postmaster]
psql template1
\dS causes a segmentation fault in the backend

From the log:

StartTransactionCommand
query: SELECT usename, relname, relkind, relhasrules FROM pg_class, pg_user
WHERE usesysid = relowner and ( relkind = 'r' OR relkind = 'i' OR relkind =
'S') and relname ~ '^pg_' and (relkind != 'i' OR relname !~ '^xinx') ORDER BY
relname
ProcessQuery
/usr/lib/postgresql/bin/postmaster: reaping dead processes...
/usr/lib/postgresql/bin/postmaster: CleanupProc: pid 294 exited with status 11

This can be isolated to the pattern-matching operator:

template1=> select * from pg_class where relname ~ '^pg_' ;
pqReadData() -- backend closed the channel unexpectedly.

------- Forwarded Message

Date: Thu, 18 Nov 1999 19:48:39 +0800
From: Chuan-kai Lin <cklin@oink.cc.ntu.edu.tw>
To: Oliver Elphick <olly@lfix.co.uk>
Subject: Re: Bug#50388: Backend close client-server channel unexpectedly

On Thu, Nov 18, 1999 at 09:18:34AM +0000, Oliver Elphick wrote:

Something must have happened to the database as it was being created.
At the moment, I would put it down to cosmic rays or something.

Through a friend who specializes in metaphysics and astronomy, I
have traced down the exact cause of our problem: PostgreSQL does
not like BIG5 encoding. If you supply "-e BIG5" to initdb, the
resulting database will be hosed. Plain and simple.

This looks like a tough one... somebody better notify the upstream
developers about this.

- -- Chuan-kai Lin

------- End of Forwarded Message

--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"To show forth thy lovingkindness in the morning, and
thy faithfulness every night." Psalms 92:2

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

_____________________________________________________________
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 Fri Nov 19 06:39:29 1999
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA88769
for <pgsql-hackers@postgresql.org>;
Fri, 19 Nov 1999 06:38:45 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (mail@sfcabop1.nettuno.it
[193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 3.3) with ESMTP id MAA25743
for <pgsql-hackers@postgresql.org>;
Fri, 19 Nov 1999 12:38:43 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 11onwo-0001K1-00; Fri, 19 Nov 1999 13:19:30 +0000
Message-ID: <38353533.B8E39770@sferacarta.com>
Date: Fri, 19 Nov 1999 12:32:04 +0100
From: jose soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.5 [it] (Win95; I)
X-Accept-Language: it
MIME-Version: 1.0
To: hackers <pgsql-hackers@postgresql.org>
Subject: pg_dump bug
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Hi,

I think I found a bug in pg_dump:
I created a table like:

CREATE TABLE ut (
Azienda CHAR(16) NOT NULL,
ragione_sociale VARCHAR(45) NOT NULL,
indirizzo CHAR(40),
inizio_attivita DATE DEFAULT CURRENT_DATE,
fine_attivita DATE
);

and pg_dump modify the structure table as:

\connect - postgres
CREATE TABLE "ut" (
"azienda" character(16) NOT NULL,
"ragione_sociale" character varying(45) NOT NULL,
"indirizzo" character(40),
"inizio_attivita" date DEFAULT date( 'current'::datetime + '0
sec') NOT NULL,
"fine_attivita" date);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If I try to recreate the table I have this:
ERROR: parser: parse error at or near "'"

Any ideas ?

JosО©╫

From bouncefilter Fri Nov 19 07:31:29 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 HAA94351
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 07:31:18 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
HAA09319;
Fri, 19 Nov 1999 07:28:43 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911191228.HAA09319@candle.pha.pa.us>
Subject: Re: [HACKERS] 7.0 status request
In-Reply-To: <3834EFCF.48875CF1@alumni.caltech.edu> from Thomas Lockhart at
"Nov 19, 1999 06:35:59 am"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Fri, 19 Nov 1999 07:28:43 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Here are the major open issues for 7.0 that I remember:
Foreign Keys - Jan
WAL - Vadim
Function args - Tom
System indcxes - Bruce
Outer joins and new multi-query parse tree are questionable items for
7.0.

You might include "join syntax", which will be ready even if outer
joins are not.

Also, didn't some folks express concern that indices on system tables
would make the backend more fragile? Did we resolve that issue?

We have indexes on most system tables and it isn't a problem currently.

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

From bouncefilter Fri Nov 19 09:46:31 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 JAA10036
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 09:45:51 -0500 (EST) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with ESMTP id PAA02491;
Fri, 19 Nov 1999 15:30:14 +0300 (MSK)
Date: Fri, 19 Nov 1999 15:30:14 +0300 (MSK)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: jose soares <jose@sferacarta.com>
cc: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pg_dump bug
In-Reply-To: <38353533.B8E39770@sferacarta.com>
Message-ID: <Pine.GSO.3.96.SK.991119152941.3910u-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=koi8-r
Content-Transfer-Encoding: 8bit

I confirm this bug for 6.5.3, Linux

Oleg

On Fri, 19 Nov 1999, jose soares wrote:

Date: Fri, 19 Nov 1999 12:32:04 +0100
From: jose soares <jose@sferacarta.com>
To: hackers <pgsql-hackers@postgreSQL.org>
Subject: [HACKERS] pg_dump bug

Hi,

I think I found a bug in pg_dump:
I created a table like:

CREATE TABLE ut (
Azienda CHAR(16) NOT NULL,
ragione_sociale VARCHAR(45) NOT NULL,
indirizzo CHAR(40),
inizio_attivita DATE DEFAULT CURRENT_DATE,
fine_attivita DATE
);

and pg_dump modify the structure table as:

\connect - postgres
CREATE TABLE "ut" (
"azienda" character(16) NOT NULL,
"ragione_sociale" character varying(45) NOT NULL,
"indirizzo" character(40),
"inizio_attivita" date DEFAULT date( 'current'::datetime + '0
sec') NOT NULL,
"fine_attivita" date);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If I try to recreate the table I have this:
ERROR: parser: parse error at or near "'"

Any ideas ?

JosО©╫

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

_____________________________________________________________
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 Fri Nov 19 07:38:30 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 HAA94918
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 07:37:39 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
HAA09653;
Fri, 19 Nov 1999 07:35:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911191235.HAA09653@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dump bugu
In-Reply-To: <38353533.B8E39770@sferacarta.com> from jose soares at "Nov 19,
1999 12:32:04 pm"
To: jose soares <jose@sferacarta.com>
Date: Fri, 19 Nov 1999 07:35:14 -0500 (EST)
CC: hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Hi,

I think I found a bug in pg_dump:
I created a table like:

CREATE TABLE ut (
Azienda CHAR(16) NOT NULL,
ragione_sociale VARCHAR(45) NOT NULL,
indirizzo CHAR(40),
inizio_attivita DATE DEFAULT CURRENT_DATE,
fine_attivita DATE
);

and pg_dump modify the structure table as:

\connect - postgres
CREATE TABLE "ut" (
"azienda" character(16) NOT NULL,
"ragione_sociale" character varying(45) NOT NULL,
"indirizzo" character(40),
"inizio_attivita" date DEFAULT date( 'current'::datetime + '0
sec') NOT NULL,
"fine_attivita" date);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Strange, but the query looks fine, and creates fine here in the current
sources. We had a quoting bug in defaults at some point. What version
are you using?

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

From bouncefilter Fri Nov 19 07:41:30 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA95539
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 07:41:18 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
HAA09678;
Fri, 19 Nov 1999 07:36:30 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911191236.HAA09678@candle.pha.pa.us>
Subject: Re: [HACKERS] Getting OID in psql of recent insert
In-Reply-To: <1195.942990002@sss.pgh.pa.us> from Tom Lane at "Nov 19,
1999 00:40:02 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 19 Nov 1999 07:36:30 -0500 (EST)
CC: "Aaron J. Seigo" <aaron@gtv.ca>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

On Thu, 18 Nov 1999, Bruce Momjian wrote:

OK, I am dealing with this in the book. What are oids good for then?

once inserted, a row keeps its oid. so, when performing complex
selects, i'll often grab the oid too... do some tests on the returned
values, and if an action is appropriate on that row, i reference it by
its oid. the only chance of this failing is if the database is dumped
then restored between the select and the update (not gonna happen, as
the program requires the database available for execution)... using
the oid this way, its often simpler and faster to update a known row,
especially when the initial select involved many fields.

Yes, I use 'em the same way. I think an OID is kind of like a pointer
in a C program: good for fast, unique access to an object within the
context of the execution of a particular application (and maybe not
even that long). You don't write pointers into files to be used again
by other programs, though, and in the same way an OID isn't a good
candidate for a long-lasting reference from one table to another.

My feeling was that oid's are fine for joins in cases where the number
is not visible to the user, because they are not sequential. Does that
make sense, or is that too broad a usage?

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

From bouncefilter Fri Nov 19 09:57:31 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 JAA12319
for <hackers@postgreSQL.org>; Fri, 19 Nov 1999 09:56:48 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11opL1-0003kGC; Fri, 19 Nov 99 15:48 MET
Message-Id: <m11opL1-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] psql & regress tests
To: tgl@sss.pgh.pa.us (Tom Lane)
Date: Fri, 19 Nov 1999 15:48:35 +0100 (MET)
Cc: wieck@debis.com, pgman@candle.pha.pa.us, peter_e@gmx.net,
hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <1262.942990632@sss.pgh.pa.us> from "Tom Lane" at Nov 19,
99 00:50:32 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Tom Lane wrote:

wieck@debis.com (Jan Wieck) writes:

Bruce Momjian wrote:

Now that we know numeric is working, can we make the test run faster in
the default mode?

It is already down to 100 digits after the decimal point. I
don't want to lower it too much, but maybe 30 or 50 are
enough too - no?

Since multiply and so on are presumably O(N^2), cutting the precision
to 30 might cut the runtime by almost a factor of 10.

Jan probably has a better idea than the rest of us whether a test of
100, or 30, or 10 digits is likely to expose bugs that would not be
exposed by a test with less precision --- that depends on whether the

I created a new default numeric test using numbers of range
10,10 as input only. It doesn't save that much of time as you
expect, but you're right anyways.

Will commit it later, together with the new parallel test
suite.

BTW: The parallel problems I encountered aren't anything.
Starting the postmaster with -D... isn't the same as setting
PGDATA environment - as it IMHO should be. It happened that I
killed the test-install postmaster, started with -D pointing
into my temp dirs, with SIGKILL. It corrupted the pg_control
file of my default installation :-}

And if you do not have an initialized data directory at the
compiled in default location, postmaster doesn't startup with
-D at all.

Vadim, could you take a look at it?

Jan

--

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

From bouncefilter Fri Nov 19 10:08: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 KAA14836
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 10:08:18 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA02351;
Fri, 19 Nov 1999 10:07:45 -0500 (EST)
To: jose soares <jose@sferacarta.com>
cc: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pg_dump bug
In-reply-to: Your message of Fri, 19 Nov 1999 12:32:04 +0100
<38353533.B8E39770@sferacarta.com>
Date: Fri, 19 Nov 1999 10:07:44 -0500
Message-ID: <2349.943024064@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

jose soares <jose@sferacarta.com> writes:

I think I found a bug in pg_dump:

It's not pg_dump's fault; it's just putting out what's in the system
tables, and "date( 'current'::datetime + '0 sec')" is how the 6.5.*
parser translates DEFAULT CURRENT_DATE. (Which is inconsistent with
how it translates CURRENT_DATE in other contexts, but nevermind.)

The failure actually comes up because the 6.5.* parser can't cope with
"x::y"-style typecasts in default expressions; it translates them to
a syntactically invalid string. CAST ... AS doesn't work either, BTW.

I have ripped out and rewritten all of that cruft for 7.0, which is why
it works now (more or less). I dunno if it's worth trying to patch
around this particular bug in the default-handling code in 6.5.*.
It's got so many others :-(

Current sources still have a problem with this example, which is that
the default expression gets prematurely constant-folded:
CREATE TABLE ut (d1 DATE DEFAULT CURRENT_DATE);
pg_dumps as
CREATE TABLE "ut" (
"d1" date DEFAULT '11-19-1999'::date);
Drat. I thought I'd taken care of that class of problems...

regards, tom lane

From bouncefilter Fri Nov 19 10:17:33 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 KAA16445
for <pgsql-hackers@postgresql.org>;
Fri, 19 Nov 1999 10:17:20 -0500 (EST) (envelope-from hook@aktrad.ru)
Received: from sloth (sloth.aktrad.ru [195.218.140.13])
by ns1.aktrad.ru (8.9.3/8.9.3) with SMTP id SAA25841
for <pgsql-hackers@postgresql.org>;
Fri, 19 Nov 1999 18:16:43 +0300 (MSK)
Message-ID: <181801bf32a1$0cfd6600$0d8cdac3@aktrad.ru>
From: "Gene Sokolov" <hook@aktrad.ru>
To: <pgsql-hackers@postgresql.org>
Subject: Curiously confused query parser.
Date: Fri, 19 Nov 1999 18:16:26 +0300
MIME-Version: 1.0
Content-Type: text/plain;
charset="koi8-r"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2014.211
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211

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

(a side note - wouldn't it be helpful to have a little more info about the
build, namely its time stamp and/or the CVS time stamp)

test=> \d ord
Table    = ord
+----------------------------------+----------------------------------+-----
--+
|              Field               |              Type                |
Length|
+----------------------------------+----------------------------------+-----
--+
| id                               | int4                             |
4 |
| pos                              | int4                             |
4 |
| tp                               | int4                             |
4 |
+----------------------------------+----------------------------------+-----
--+

test=> select * from ord;
id|pos|tp
--+---+--
1| 1| 1
2| 2| 1
3| 3| 2
4| 1| 2
5| 3| 1
(5 rows)

This query is fine:

test=> select o1.id from ord as o1, ord as o2 where o1.pos>2 and o2.pos<2
test-> and o1.tp=o2.tp;
id
--
5
3
(2 rows)

And this one is invalid:

test=> select o1.id from ord as o1, ord as o2 where o1.pos>2 and o2.pos<2
test-> and o1.tp=o2.tp and ord.id>3;
id
--
5
5
3
3
(4 rows)

This query should probably fail instead of returning an invalid result. MS
SQL 6.5 does just that:

Msg 107, Level 16, State 3
The column prefix 'ord' does not match with a table name or alias name used
in the query.

Gene Sokolov

From bouncefilter Fri Nov 19 10:25:34 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 KAA17563
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 10:24:52 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA22495;
Fri, 19 Nov 1999 15:24:52 GMT
Sender: lockhart@hub.org
Message-ID: <38356BC4.BE79F5BF@alumni.caltech.edu>
Date: Fri, 19 Nov 1999 15:24: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: Oleg Bartunov <oleg@sai.msu.su>
CC: jose soares <jose@sferacarta.com>, hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pg_dump bug
References: <Pine.GSO.3.96.SK.991119152941.3910u-100000@ra>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I confirm this bug for 6.5.3, Linux

Hmm. I'm running a more-or-less current development tree, and don't
see a problem (on Linux also). Does someone want to track it down??

Although Jose may have marked the line causing a problem, perhaps
someone can more explicitly identify the offending syntax?

- Thomas

I think I found a bug in pg_dump:
CREATE TABLE "ut" (
"azienda" character(16) NOT NULL,
"ragione_sociale" character varying(45) NOT NULL,
"indirizzo" character(40),
"inizio_attivita" date DEFAULT date( 'current'::datetime + '0
sec') NOT NULL,
"fine_attivita" date);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If I try to recreate the table I have this:
ERROR: parser: parse error at or near "'"

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

From bouncefilter Fri Nov 19 10:33:31 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 KAA19051
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 10:33:08 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA22508;
Fri, 19 Nov 1999 15:32:54 GMT
Sender: lockhart@hub.org
Message-ID: <38356DA6.539BD371@alumni.caltech.edu>
Date: Fri, 19 Nov 1999 15:32:54 +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: Bruce Momjian <pgman@candle.pha.pa.us>, Don Baccus <dhogaza@pacifier.com>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Primary key requires SERIAL
References: <1502.942994083@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I think it's poor practice to try to enforce such a restriction via
the grammar, because that way you cannot generate an error more
specific than "parse error near FOO". It'd be better to allow the
same ColQualifier for SERIAL as for any other column type, and then to
put sanity checks in analyze.c that would complain about conflicting
specifications. We have, or should have, most of those checks in
place already to catch conflicting ColQualifier entries for a plain
column type (eg, "foo int4 NULL NOT NULL"). Also, I do not like
generating hard errors for specifications that are merely redundant
("foo SERIAL NOT NULL"); is there any basis in the SQL spec for
refusing such constructs?

Basis? Basis?? Since SERIAL is an extension, there is not anything
defined explicitly. And SQL tends to be a context-sensitive language
(hmm, what's the term for that?) so it does things in different ways
all over the place; it's not very self-consistant. What *should*
happen with a declaration like "foo int NOT NULL NOT NULL"? One could
argue that the backend should just do it, or perhaps should reject
this as a possibly corrupted declaration.

When I first implemented SERIAL, I'm pretty sure I would have had
trouble checking for conflicting qualifiers. But maybe now all the
pieces are there to do it right. Will look at it...

Anyway, I agree with your points, and will put this on my ToDo. btw, I
still have an item about the parser swallowing multiple SERIAL or
PRIMARY KEY declarations (don't remember which right now); will get to
that also.

- Thomas

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

From bouncefilter Fri Nov 19 10:37:31 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA19817
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 10:37:21 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA02552;
Fri, 19 Nov 1999 10:36:03 -0500 (EST)
To: "Gene Sokolov" <hook@aktrad.ru>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Curiously confused query parser.
In-reply-to: Your message of Fri, 19 Nov 1999 18:16:26 +0300
<181801bf32a1$0cfd6600$0d8cdac3@aktrad.ru>
Date: Fri, 19 Nov 1999 10:36:02 -0500
Message-ID: <2550.943025762@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

This query is fine:

test=> select o1.id from ord as o1, ord as o2 where o1.pos>2 and o2.pos<2

test-> and o1.tp=o2.tp;

id
--
5
3
(2 rows)

And this one is invalid:

test=> select o1.id from ord as o1, ord as o2 where o1.pos>2 and o2.pos<2

test-> and o1.tp=o2.tp and ord.id>3;

id
--
5
5
3
3
(4 rows)

It's not invalid, at least not according to Postgres' view of the world;
your reference to ord.id adds an implicit "FROM ord AS ord" to the FROM
clause, turning the query into a 3-way join. The output is correct for
that interpretation.

Implicit FROM clauses are a POSTQUEL leftover that is not to be found
in the SQL92 spec. There's been some talk of emitting a warning message
when one is added, because we do regularly see questions from confused
users. But if we took the feature out entirely, we'd doubtless break
some existing applications :-(

regards, tom lane

From bouncefilter Fri Nov 19 10:40:32 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 KAA20467
for <hackers@postgresql.org>; Fri, 19 Nov 1999 10:40:13 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA22523;
Fri, 19 Nov 1999 15:40:30 GMT
Sender: lockhart@hub.org
Message-ID: <38356F6E.4E9E8F37@alumni.caltech.edu>
Date: Fri, 19 Nov 1999 15:40: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: Postgres Hackers List <hackers@postgresql.org>
CC: Lamar Owen <lamar.owen@wgcr.org>
Subject: Mandrake Postgres RPMs
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I've installed Mandrake 6.1 on a new laptop (an early Christmas
present :) and notice a little trouble with the RPMs. Somehow, they
include the old postgresql-clients-6.4.2 package as well as all of the
-6.5.1 packages. I assume that RedHat 6.1 does not show the same
problem?

Does anyone already talk to the Mandrake folks, or run Mandrake and
would like to pursue this?

btw, the RPM installation was *really nice*!!!!! For some reason the
server packages were not installed when I built the system, and I
installed later so got to see it happen. The RPM automatically
unpacked everything, did the initdb, and a
"/etc/rc.d/init.d/postgresql start" got me a server.

One detail: Mandrake defines a Postgres user, but disables the
password. I added the password and was then able to log in as the
Postgres user and add other users. Is that the preferred way to do
it??

- Thomas

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

From bouncefilter Fri Nov 19 11:04:32 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 LAA24253
for <pgsql-hackers@postgresql.org>;
Fri, 19 Nov 1999 11:04:22 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA17217;
Fri, 19 Nov 1999 10:55:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911191555.KAA17217@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_dump bug
In-Reply-To: <Pine.GSO.3.96.SK.991119152941.3910u-100000@ra> from Oleg
Bartunov
at "Nov 19, 1999 03:30:14 pm"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Fri, 19 Nov 1999 10:55:02 -0500 (EST)
CC: jose soares <jose@sferacarta.com>, hackers <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset koi8-r unsupported, filtering to ASCII...]

I confirm this bug for 6.5.3, Linux

OK, seems like it is only 6.5.* tree and not development tree, which
means development has a fix that was too risky for 6.5.*. Seems user
will have to wait for 7.0.

Oleg

On Fri, 19 Nov 1999, jose soares wrote:

Date: Fri, 19 Nov 1999 12:32:04 +0100
From: jose soares <jose@sferacarta.com>
To: hackers <pgsql-hackers@postgreSQL.org>
Subject: [HACKERS] pg_dump bug

Hi,

I think I found a bug in pg_dump:
I created a table like:

CREATE TABLE ut (
Azienda CHAR(16) NOT NULL,
ragione_sociale VARCHAR(45) NOT NULL,
indirizzo CHAR(40),
inizio_attivita DATE DEFAULT CURRENT_DATE,
fine_attivita DATE
);

and pg_dump modify the structure table as:

\connect - postgres
CREATE TABLE "ut" (
"azienda" character(16) NOT NULL,
"ragione_sociale" character varying(45) NOT NULL,
"indirizzo" character(40),
"inizio_attivita" date DEFAULT date( 'current'::datetime + '0
sec') NOT NULL,
"fine_attivita" date);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

If I try to recreate the table I have this:
ERROR: parser: parse error at or near "'"

Any ideas ?

Jos_

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

_____________________________________________________________
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

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

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

From bouncefilter Fri Nov 19 11:00:33 1999
Received: from charleston.softhome.net (qmailr@charleston.SoftHome.net
[204.144.231.41]) by hub.org (8.9.3/8.9.3) with SMTP id LAA23788
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 11:00:22 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 19143 invoked by uid 417); 19 Nov 1999 16:28:20 -0000
Received: from sentec.demon.nl (HELO joost) (212.238.106.25)
by smtp.softhome.net with SMTP; 19 Nov 1999 16:28:20 -0000
Message-ID: <001f01bf32a6$e40117a0$8602a8c0@sentec.demon.nl>
From: "J. Roeleveld" <j.roeleveld@softhome.net>
To: <pgsql-hackers@postgreSQL.org>
References: <38356F6E.4E9E8F37@alumni.caltech.edu>
Subject: Re: [HACKERS] Mandrake Postgres RPMs
Date: Fri, 19 Nov 1999 16:56:48 +0100
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

One detail: Mandrake defines a Postgres user, but disables the
password. I added the password and was then able to log in as the
Postgres user and add other users. Is that the preferred way to do
it??

I usually 'su' to the postgres - user from root, and then create a
super-user-account
for myself, and then do all the other stuff from there.
I don't know how other people think about this, but I have found that
the less passwords there are into a system, the harder it is for people to
break in.

Joost Roeleveld

From bouncefilter Fri Nov 19 12:15: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 MAA35848
for <hackers@postgresql.org>; Fri, 19 Nov 1999 12:15:24 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id MAA24506;
Fri, 19 Nov 1999 12:14:26 -0500
Message-ID: <3835856B.CDEC0413@wgcr.org>
Date: Fri, 19 Nov 1999 12:14:20 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Postgres Hackers List <hackers@postgresql.org>
Subject: Re: Mandrake Postgres RPMs
References: <38356F6E.4E9E8F37@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

I've installed Mandrake 6.1 on a new laptop (an early Christmas
present :) and notice a little trouble with the RPMs. Somehow, they
include the old postgresql-clients-6.4.2 package as well as all of the
-6.5.1 packages. I assume that RedHat 6.1 does not show the same
problem?

That is a Mandrake problem. They haven't really followed the
development of the new RPM's like RedHat did for RedHat 6.1. So, they
shipped mutually exclusive RPMs for PostgreSQL because they didn't pay
close enough attention. Also, the RPM's shipped with Mandrake 6.1 are
somewhat older than what shipped with RedHat 6.1. And RedHat 6.1 does
not include any older RPMs of PostgreSQL. (http://www.cheapbytes.com
for real cheap RedHat CD's..... :-)) HOWEVER, f you have a laptop, you
may want to wait until RedHat 6.2 is released, as there are some issues
with some laptops and RedHat 6.1's kernel -- although I think that most
of the troubles are with Toshiba's.

Does anyone already talk to the Mandrake folks, or run Mandrake and
would like to pursue this?

I have e-mailed the Mandrake folks on two occasions -- haven't received
a reply. HOWEVER, they will pull whatever is the current RPM set from
ftp.postgresql.org when they get to another release point (AFAIK).

btw, the RPM installation was *really nice*!!!!! For some reason the
server packages were not installed when I built the system, and I
installed later so got to see it happen. The RPM automatically
unpacked everything, did the initdb, and a
"/etc/rc.d/init.d/postgresql start" got me a server.

Well, thank you. It is virtually impossible to force the installation
of the server package for the OS install without forcing it for all
installs -- which I believe we didn't want -- the purpose of splitting
it out, IIRC, was to allow a client-only installation for those who
might want such a beast.

As I said, that was a slightly older RPM set than RedHat 6.1 shipped --
Mandrake 6.1 shipped before RH 6.1 by a couple of weeks. The Mandrake
people pulled the 6.5.1-0.8 RPM's off of RawHide -- apparently about two
days before I finalized the upgrading stuff -- but after I put in the
automatic initdb, I believe.

One detail: Mandrake defines a Postgres user, but disables the
password. I added the password and was then able to log in as the
Postgres user and add other users. Is that the preferred way to do
it??

RedHat 6.1 also does this. This way, passwordless accounts are not left
after an installation as a security hole. BTW, this is the way I
normally run -- if I want to do stuff as postgres, I su to root then su
to postgres, as I don't want to allow direct logins to postgres. Of
course, to each his own. The RPM post install script could feed a
default password in, but that would be just as bad as no password at
all.

Glad you're enjoying it....

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

From bouncefilter Fri Nov 19 12:28: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 MAA37431
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 12:27:21 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id MAA24548;
Fri, 19 Nov 1999 12:24:58 -0500
Message-ID: <383587E3.DC962279@wgcr.org>
Date: Fri, 19 Nov 1999 12:24:51 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] 7.0 status request
References: <199911190343.WAA23334@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Here are the major open issues for 7.0 that I remember:

[snip]

Is this currect?

Is large tuple support not open at this time? I know it is one of the
things that has been wanted for ages. I know a discussion about it
happened not long ago, but no one stepped up to the plate on it.

--
Lamar Owen
WGCR Internet Radio

From bouncefilter Fri Nov 19 13: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 NAA43472
for <pgsql-hackers@postgresql.org>;
Fri, 19 Nov 1999 13:18:09 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id NAA24643
for <pgsql-hackers@postgresql.org>; Fri, 19 Nov 1999 13:18:12 -0500
Message-ID: <3835945D.B5F82B95@wgcr.org>
Date: Fri, 19 Nov 1999 13:18:05 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: LinuxPlanet RDBMS comparison article series.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Check out http://www.linuxplanet.com/linuxplanet/tutorials/1251/1/

Some interesting comments in there on us. This is a tutorial/comparison,
so don't expect extreme accuracy -- but th author does have some
comments on features and documentation for PostgreSQL.

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

From bouncefilter Fri Nov 19 14:38:36 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 OAA53049
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 14:38:04 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11otja-0003kKC; Fri, 19 Nov 99 20:30 MET
Message-Id: <m11otja-0003kKC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: New regression driver
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Fri, 19 Nov 1999 20:30:14 +0100 (MET)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

I't committed.

There is a new shell script run_check.sh in the regression
test directory. It is driven by the conficuration file
./sql/run_check.tests and runs most of our tests parallel. It
is invoked with the new GNUmakefile target 'runcheck'.

The regress.sh is using the new tests file too by extracting
the tests to run via awk, so ./sql/tests is obsolete now and
subject to be removed soon.

Bruce Momjian wrote:

Any modifications to shared pg_ tables would be a problem. Also, pg_log
and pg_variable locking is not happening in there either, is it?

Thus, it does a complete independant database installation
below the regression test, starting it's own postmaster (and
terminating it at the end, of course). The entire test suite
can be run without even shutting down the currently installed
database.

So a

...src > ./configure
...src > make
...src > cd test/regression
...src/test/regression > make clean all runcheck

sequence will compile and temporarily install the new build
under the regression path, and then run all the tests against
it.

I think if my new test driver has settled, we should change
the GNUmakefile to just print some messages if 'make runtest'
is typed. The current runtest target should IMHO still be
availabe under another name, to test the real life
installation created by 'make install'.

Alternatively (IMHO better) some parameter to run_check.sh
could tell if it should create it's own, temporary
installation, or if it should use the existing installed
database system and the already running postmaster.

Tom Lane wrote:

In other words, you've already exposed a bug! Right on!

Absolutely right and I've commented out that code for now.
It is in utils/cache/catcache.c line 996. The comments say
that the code should prevent the backend from entering
infinite recursion while loading new cache entries. But the
flag used for it seems to live in shared memory, thus it is
affected by other backends too. If the flag is true doesn't
tell if a backend set it itself, or if another one did. If we
really need this check, it must be implemented in another
way.

Another bug I discoverd is that Vadims WAL code allways looks
for the pg_control file in the PGDATA or compiled in default
directory, ignoring the -D switch. Haven't fixed it up to
now, but run_check.sh uses PGDATA, so it's safe at the
moment.

I ran the old regress.sh using the default installation
parallel to the run_check.sh using it's own installation and
postmaster.

Jan

--

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

From bouncefilter Fri Nov 19 14:51:34 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA54814
for <pgsql-hackers@postgresql.org>;
Fri, 19 Nov 1999 14:51:31 -0500 (EST)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id OAA10327
for <pgsql-hackers@postgresql.org>;
Fri, 19 Nov 1999 14:51:27 -0500 (EST)
Message-ID: <3835A941.605E9B4D@southeast.net>
Date: Fri, 19 Nov 1999 14:47:13 -0500
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: All forked up
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I need some Unix guidance.

Foolishly or not, I designed the new PostgreSQL logging subsystem
to run as a process. It's forked off a function called by the
Postmaster main program right before the if(...)pmdaemonize
statements -- meaning that the shared memory enviroment has been
established, but the signals have not yet been attached.

When I issue the fork() call, it successfully creates a child process,
but the child is DOA. Investigation reveals a signal 5 trace/breakpoint
trap at the fork.

How do I prevent this? I presume you can mask it, but is that really
what I want to do?

TIA,

Tim Holloway

From bouncefilter Fri Nov 19 15:04:34 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 PAA56252
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 15:03:39 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11ou7m-0003kKC; Fri, 19 Nov 99 20:55 MET
Message-Id: <m11ou7m-0003kKC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] 7.0 status request
To: pgman@candle.pha.pa.us (Bruce Momjian)
Date: Fri, 19 Nov 1999 20:55:14 +0100 (MET)
Cc: lockhart@alumni.caltech.edu, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199911191228.HAA09319@candle.pha.pa.us> from "Bruce Momjian" at
Nov 19, 99 07:28:43 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Bruce Momjian wrote:

Here are the major open issues for 7.0 that I remember:
Foreign Keys - Jan
WAL - Vadim
Function args - Tom
System indcxes - Bruce
Outer joins and new multi-query parse tree are questionable items for
7.0.

You might include "join syntax", which will be ready even if outer
joins are not.

Also, didn't some folks express concern that indices on system tables
would make the backend more fragile? Did we resolve that issue?

We have indexes on most system tables and it isn't a problem currently.

It is, because a corrupted index on a system table cannot be
corrected by drop/create, as a user defined index could be.

I don't know why and when reindexdb disappeared, but that
script was a last resort for exactly the situation of a
corrupted system index. Let me take a look if this
functionality could easily be recreated.

Jan

--

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

From bouncefilter Fri Nov 19 15:14:37 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 PAA60736
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 15:13:44 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11ouHr-0003kIC; Fri, 19 Nov 99 21:05 MET
Message-Id: <m11ouHr-0003kIC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Curiously confused query parser.
To: hook@aktrad.ru (Gene Sokolov)
Date: Fri, 19 Nov 1999 21:05:39 +0100 (MET)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <181801bf32a1$0cfd6600$0d8cdac3@aktrad.ru> from "Gene Sokolov" at
Nov 19, 99 06:16:26 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Gene Sokolov wrote:

And this one is invalid:

test=> select o1.id from ord as o1, ord as o2 where o1.pos>2 and o2.pos<2
test-> and o1.tp=o2.tp and ord.id>3;
id
--
5
5
3
3
(4 rows)

This query should probably fail instead of returning an invalid result. MS
SQL 6.5 does just that:

Msg 107, Level 16, State 3
The column prefix 'ord' does not match with a table name or alias name used
in the query.

Seems PostgreSQL tries to be a little too smart. It
automatically adds another rangetable entry for ORD, so the
query is executed as

test=> select o1.id from ord as o1, ord as o2, ord as auto_rte
test-> where o1.pos>2 and o2.pos<2
test-> and o1.tp=o2.tp and auto_rte.id>3;

For this query, the result is O.K.

I don't know if this is according to the SQL specs and MS is
wrong, or if PostgreSQL is violating the specs. Thomas?

Jan

--

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

From bouncefilter Fri Nov 19 16:42:35 1999
Received: from loopy.berkhirt.com (loopy.berkhirt.com [209.220.85.54])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA73546
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 16:42:22 -0500 (EST)
(envelope-from bhirt@loopy.berkhirt.com)
Received: (from bhirt@localhost)
by loopy.berkhirt.com (8.9.3/8.8.7) id PAA08482;
Fri, 19 Nov 1999 15:41:49 -0600
Date: Fri, 19 Nov 1999 15:41:49 -0600
From: Brian Hirt <bhirt@mobygames.com>
To: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Cc: bhirt@loopy.berkhirt.com
Subject: Re: [HACKERS] 7.0 status request
Message-ID: <19991119154149.C8066@loopy.berkhirt.com>
Reply-To: bhirt@mobygames.com
References: <199911191228.HAA09319@candle.pha.pa.us>
<m11ou7m-0003kKC@orion.SAPserv.Hamburg.dsh.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us
In-Reply-To: <m11ou7m-0003kKC@orion.SAPserv.Hamburg.dsh.de>;
from Jan Wieck on Fri, Nov 19, 1999 at 08:55:14PM +0100
X-PC-Gaming: http://www.mobygames.com/

On Fri, Nov 19, 1999 at 08:55:14PM +0100, Jan Wieck wrote:

It is, because a corrupted index on a system table cannot be
corrected by drop/create, as a user defined index could be.

I don't know why and when reindexdb disappeared, but that
script was a last resort for exactly the situation of a
corrupted system index. Let me take a look if this
functionality could easily be recreated.

Jan,

I submitted a very small patch to dumpdb that creates SQL that will
reindex the database. It's then trivial to then redirect that output to
pgsql on UNIX. I run into this problem frequently, so I wanted
to automate the process. I never saw a reply to my post on the list,
so I wonder if it made it.

I'm not sure how reindexdb worked, but if it just generated SQL based of
the indexes in the database it would make sense to only have the SQL
generation in one common place instead of having it in dumpdb and reindexdb.
Two branches of nearly identical code would be a pain to maintain.

-brian

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

http://www.mobygames.com

From bouncefilter Fri Nov 19 16:49:36 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA74358
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 16:49:33 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
QAA24161;
Fri, 19 Nov 1999 16:49:15 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911192149.QAA24161@candle.pha.pa.us>
Subject: Re: [HACKERS] 7.0 status request
In-Reply-To: <383587E3.DC962279@wgcr.org> from Lamar Owen at "Nov 19,
1999 12:24:51 pm"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Fri, 19 Nov 1999 16:49:15 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Here are the major open issues for 7.0 that I remember:

[snip]

Is this currect?

Is large tuple support not open at this time? I know it is one of the
things that has been wanted for ages. I know a discussion about it
happened not long ago, but no one stepped up to the plate on it.

No one has claimed it. It may be too 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 19026

From bouncefilter Fri Nov 19 16:57:36 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id QAA75590
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 16:56:55 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 10875 invoked by uid 1001); 19 Nov 1999 21:56:59 -0000
Message-ID: <XFMail.991119165659.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199911190343.WAA23334@candle.pha.pa.us>
Date: Fri, 19 Nov 1999 16:56:59 -0500 (EST)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] 7.0 status request

On 19-Nov-99 Bruce Momjian wrote:

Here are the major open issues for 7.0 that I remember:

Foreign Keys - Jan
WAL - Vadim
Function args - Tom
System indcxes - Bruce

Outer joins and new multi-query parse tree are questionable items for
7.0.

Is this currect?

There was talk about purging functions from libpq. Is there any concensus
on which functions may be going away?

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

From bouncefilter Fri Nov 19 17:16:39 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA78582
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 17:16:11 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA03570;
Fri, 19 Nov 1999 17:14:52 -0500 (EST)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] 7.0 status request
In-reply-to: Your message of Fri, 19 Nov 1999 12:24:51 -0500
<383587E3.DC962279@wgcr.org>
Date: Fri, 19 Nov 1999 17:14:52 -0500
Message-ID: <3568.943049692@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Bruce Momjian wrote:

Here are the major open issues for 7.0 that I remember:

Is large tuple support not open at this time?

I think Bruce was trying to list the work items that are both large
and fairly likely to be done before 7.0. (I suspect his motivation
is to figure out what changes he should allow for while writing his
book...)

No one has spoken up and said "I will work on large tuples for 7.0",
so it's not on his list. It could still happen though.

regards, tom lane

From bouncefilter Fri Nov 19 17:26:36 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 RAA80109
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 17:25:39 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11owLb-0003kIC; Fri, 19 Nov 99 23:17 MET
Message-Id: <m11owLb-0003kIC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] 7.0 status request
To: bhirt@mobygames.com
Date: Fri, 19 Nov 1999 23:17:39 +0100 (MET)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org, bhirt@loopy.berkhirt.com
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <19991119154149.C8066@loopy.berkhirt.com> from "Brian Hirt" at
Nov 19, 99 03:41:49 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

I submitted a very small patch to dumpdb that creates SQL that will
reindex the database. It's then trivial to then redirect that output to
pgsql on UNIX. I run into this problem frequently, so I wanted
to automate the process. I never saw a reply to my post on the list,
so I wonder if it made it.

I'm not sure how reindexdb worked, but if it just generated SQL based of
the indexes in the database it would make sense to only have the SQL
generation in one common place instead of having it in dumpdb and reindexdb.
Two branches of nearly identical code would be a pain to maintain.

It's a different approach. And recreating system catalog
indices cannot work through the regular psql interface. So
your pgdump enhancement will never be able to do that.

You need to be in bootstrap processing mode (the one the
system is running in while initdb) to drop or create indices
on the system catalog tables. Therefore the postmaster must
NOT be running and you have a (very limited) interface to the
bootstrapping postgres process. Thus you'll have to talk the
*.bki.source dialect to issue commands.

I already made some tests, but they all corrupted more than
they fixed :-). Seems the semantics of the Postgres 4.2
reindexdb have been hit by changes in index handling since
1994. Not really surprising to me.

Jan

--

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

From bouncefilter Fri Nov 19 17:35:36 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 RAA81169
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 17:34:38 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA03705;
Fri, 19 Nov 1999 17:33:36 -0500 (EST)
To: Tim Holloway <mtsinc@southeast.net>
cc: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] All forked up
In-reply-to: Your message of Fri, 19 Nov 1999 14:47:13 -0500
<3835A941.605E9B4D@southeast.net>
Date: Fri, 19 Nov 1999 17:33:35 -0500
Message-ID: <3703.943050815@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tim Holloway <mtsinc@southeast.net> writes:

Foolishly or not, I designed the new PostgreSQL logging subsystem
to run as a process. It's forked off a function called by the
Postmaster main program right before the if(...)pmdaemonize
statements -- meaning that the shared memory enviroment has been
established, but the signals have not yet been attached.

I'd be inclined to think you should fork off after pmdaemonize rather
than before, but of course that makes no difference unless you're
using -S.

When I issue the fork() call, it successfully creates a child process,
but the child is DOA. Investigation reveals a signal 5 trace/breakpoint
trap at the fork.

What did your investigation consist of? That could just be the result
of your debugger trying to step through the fork. Many Unix debuggers
don't cope very well with multi-process programs.

I'm still wondering why you are bothering with an extra process, though.
By the time you get done writing the required communication support,
you'll be adding quite a large amount of code, and at least one new
failure mode for Postgres, in return for what exactly? This design
isn't making sense to me, compared to just letting the backends issue
their own logging messages.

regards, tom lane

From bouncefilter Fri Nov 19 17:40:36 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA82060
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 17:40:15 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA28222;
Fri, 19 Nov 1999 17:39:52 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911192239.RAA28222@candle.pha.pa.us>
Subject: Re: [HACKERS] 7.0 status request
In-Reply-To: <3568.943049692@sss.pgh.pa.us> from Tom Lane at "Nov 19,
1999 05:14:52 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Fri, 19 Nov 1999 17:39:52 -0500 (EST)
CC: Lamar Owen <lamar.owen@wgcr.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Bruce Momjian wrote:

Here are the major open issues for 7.0 that I remember:

Is large tuple support not open at this time?

I think Bruce was trying to list the work items that are both large
and fairly likely to be done before 7.0. (I suspect his motivation
is to figure out what changes he should allow for while writing his
book...)

Actually, the motivation was to just get a heads-up from everyone that
we are on track for 7.0. If someone wanted to cancel their offer of
adding a feature, that is usually the way we hear about it. That way,
we don't find out just before beta that someone has decided to abandon a
feature addition.

This doesn't mean they will actually complete the addition, but it does
mean that at this time they are going to attempt to complete it for 7.0.

As we get closer, the dreaded Open Items list appears to marshall forces
to get as many bugs fixed/features as possible, though Tom, your
presence is making that unnecessary because you seem to fix the bugs
as soon as they come up. In the old days, the stuff stayed in my
mailbox, and nearing beta, I would comb through for open bug reports,
make a list, and try and get as many fixed as possible.

BTW, I am writing the book assuming no additions will be made for 7.0.
If they happen, I will rewrite. If I put a feature on paper, there is
extra pressure to complete it, and I don't want 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 19026

From bouncefilter Fri Nov 19 17:48:36 1999
Received: from web2102.mail.yahoo.com (web2102.mail.yahoo.com [128.11.68.246])
by hub.org (8.9.3/8.9.3) with SMTP id RAA83371
for <pgsql-hackers@postgresql.org>;
Fri, 19 Nov 1999 17:48:21 -0500 (EST)
(envelope-from mascarim@yahoo.com)
Message-ID: <19991119224821.22387.rocketmail@web2102.mail.yahoo.com>
Received: from [24.26.131.45] by web2102.mail.yahoo.com;
Fri, 19 Nov 1999 14:48:21 PST
Date: Fri, 19 Nov 1999 14:48:21 -0800 (PST)
From: Mike Mascari <mascarim@yahoo.com>
Subject: Re: [HACKERS] 7.0 status request
To: Jan Wieck <wieck@debis.com>
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

--- Jan Wieck <wieck@debis.com> wrote:

Bruce Momjian wrote:

Here are the major open issues for 7.0 that I remember:
Foreign Keys - Jan
WAL - Vadim
Function args - Tom
System indcxes - Bruce
Outer joins and new multi-query parse tree are questionable items

for

7.0.

You might include "join syntax", which will be ready even if outer
joins are not.

Also, didn't some folks express concern that indices on system

tables

would make the backend more fragile? Did we resolve that issue?

We have indexes on most system tables and it isn't a problem

currently.

It is, because a corrupted index on a system table cannot be
corrected by drop/create, as a user defined index could be.

I don't know why and when reindexdb disappeared, but that
script was a last resort for exactly the situation of a
corrupted system index. Let me take a look if this
functionality could easily be recreated.

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

For what its worth, TRUNCATE TABLE already rebuilds indexes on TRUNCATE'd
tables, so it shouldn't be that much of a leap, one would think.

Mike Mascari
(mascarim@yahoo.com)

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

From bouncefilter Fri Nov 19 19:22:37 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 TAA95772
for <pgsql-hackers@postgresql.org>;
Fri, 19 Nov 1999 19:21:49 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgresql.org
id m11oyA6-0003kIC; Sat, 20 Nov 99 01:13 MET
Message-Id: <m11oyA6-0003kIC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] 7.0 status request
To: mascarim@yahoo.com (Mike Mascari)
Date: Sat, 20 Nov 1999 01:13:54 +0100 (MET)
Cc: wieck@debis.com, pgsql-hackers@postgresql.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <19991119224821.22387.rocketmail@web2102.mail.yahoo.com> from
"Mike Mascari" at Nov 19, 99 02:48:21 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Mike Mascari wrote:

It is, because a corrupted index on a system table cannot be
corrected by drop/create, as a user defined index could be.

I don't know why and when reindexdb disappeared, but that
script was a last resort for exactly the situation of a
corrupted system index. Let me take a look if this
functionality could easily be recreated.

For what its worth, TRUNCATE TABLE already rebuilds indexes on TRUNCATE'd
tables, so it shouldn't be that much of a leap, one would think.

Imagine a corrupted pg_attribute_attrelid_index. What would
it be good for to do a TRUNCATE TABLE pg_attribute? For god's
sake, it's not permitted.

I'm talking about corrupted system catalog indices! There's a
substantial difference for them. If only one is missing, you
might not be able to even connect to that database because
the backend wouldn't start up. The problem here is, that the
system catalog's partially reside in a shared memory cache
during the lifetime of a postmaster! And remember, one
postmaster can server many databases. There are REALLY
different semantics!

Please folks, it's nice if you succeded in recovering from a
corrupted index. But as long as it's name didn't start with
pg_, it's not what I'm talking about.

Maybe a directly issued index_build() from the bootstrap
interface might help. Will create another bootparser command
and give it a try.

Jan

--

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

From bouncefilter Fri Nov 19 20:33:38 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA05076
for <hackers@postgresql.org>; Fri, 19 Nov 1999 20:32:59 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63952 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sBTcv158093>; Sat, 20 Nov 1999 02:32:43 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11ozQE-0000PE-00
for hackers@postgresql.org; Sat, 20 Nov 1999 02:34:38 +0100
Date: Sat, 20 Nov 1999 02:34:38 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: create/alter user extension syntax
Message-ID: <Pine.LNX.4.20.9911190103100.714-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

I tried the following:

{CREATE|ALTER} USER username
[ WITH ID/UID/<whatever> number ]
[ WITH PASSWORD password ]
[ etc. as usual ]

which gives shift/reduce conflicts, even if I make PASSWORD and
ID/whatever a pure keyword (WITH is already one). So that won't work.

I am currently basing my "experiments" on CREATE USER name [ SYSID nr ] [
WITH PASSWORD ... ] ... which allows SYSID to be a ColId. Any better (and
working) syntax suggestions are welcome.

(Also, the idea would be to reuse "SYSID" for a CREATE GROUP (any day now
;) statement, so no UID.)

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

From bouncefilter Sat Nov 20 19:04:25 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA52476
for <pgsql-hackers@postgresql.org>;
Sat, 20 Nov 1999 19:03:51 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62429 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sBnPK49559>; Sun, 21 Nov 1999 01:03:34 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11p07y-0000cL-00; Sat, 20 Nov 1999 03:19:50 +0100
Date: Sat, 20 Nov 1999 03:19:49 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Vince Vielhaber <vev@michvhf.com>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: RE: [HACKERS] 7.0 status request
In-Reply-To: <XFMail.991119165659.vev@michvhf.com>
Message-ID: <Pine.LNX.4.20.9911200319120.1512-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 1999-11-19, Vince Vielhaber mentioned:

There was talk about purging functions from libpq. Is there any concensus
on which functions may be going away?

As far as I'm concerned, the printing functions only have a few more weeks
to live ;)

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

From bouncefilter Sat Nov 20 19:04:25 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA52460
for <hackers@postgresql.org>; Sat, 20 Nov 1999 19:03:31 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62353 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sBnP8166300>; Sun, 21 Nov 1999 01:03:22 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11p0As-0000cP-00; Sat, 20 Nov 1999 03:22:50 +0100
Date: Sat, 20 Nov 1999 03:22:50 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Jan Wieck <wieck@debis.com>
cc: "Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>,
hackers@postgresql.org
Subject: Re: [HACKERS] psql & regress tests
In-Reply-To: <m11obJH-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.LNX.4.20.9911200320160.1512-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 1999-11-19, Jan Wieck mentioned:

I'm actually doing some tests if the 'make check' would be
possible. I.e. doing a complete install with POSTGRESDIR
below the regress dir, running initdb with the libdir and
datadir pointing into there too, then starting new postmaster
on a different port in background etc., etc., etc..

That would make it possible to do a complete check without
doing a regular install at all.

Wasn't that exactly what my conceptual script intended to do? Great to see
some other people thinking in the same direction. The main point is to
have the tests run before any installation is done. Sounds like we're on
track . . .

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

From bouncefilter Sat Nov 20 19:04:30 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA52479
for <pgsql-hackers@postgresql.org>;
Sat, 20 Nov 1999 19:04:02 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62569 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sBnPd164252>; Sun, 21 Nov 1999 01:03:53 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11p0Q7-0000cV-00; Sat, 20 Nov 1999 03:38:35 +0100
Date: Sat, 20 Nov 1999 03:38:35 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Getting OID in psql of recent insert
In-Reply-To: <762.942983114@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.20.9911200323100.1512-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 1999-11-18, Tom Lane mentioned:

It'd certainly be easy enough for psql to save off the OID anytime it
gets an "INSERT nnn" command response. The missing link is to invent
a way for a psql script to access that value and insert it into
subsequent SQL commands.

Okay, I guess I'm way ahead of everyone here. It is in fact only a matter
of adding a few lines to save the oid in a variable, and all the
infrastructure for doing this is already present. In fact, I was going to
do this in the next few days.

testdb=> \set singlestep on
testdb=> \set sql_interpol '#'
testdb=> \set foo 'pg_class'
testdb=> select * from #foo#;
***(Single step mode: Verify query)**************
QUERY: select * from pg_class
***(press return to proceed or enter x and return to
cancel)********************
x
testdb=>

If you want to attack this, I'd suggest thinking a little larger than
just the last-OID problem. I'd like to be able to save off both
insertion OIDs and values extracted by SELECTs into named variables
of some sort, and then insert those values into as many later commands
as I want. Right now there's no way to do any such thing in a psql
script; you have to move up a level of difficulty into ecpg or pgtcl
or even C code if your application needs this. Plain psql scripts
would become substantially more powerful if psql had a capability
like this.

Hmm, saving the SELECT results in a variable sounds like a great
idea. I'll work on that. But in general, all the framework for this sort
of thing is already there as you see.

OTOH: we shouldn't ask psql to do everything under the sun. I'd
certainly think that it'd be unreasonable to try to do conditional
evaluation or looping in psql scripts, for instance. Maybe the right

I actually had (simple) conditional expressions on my list, but loops are
not possible in the current design. Since I just redesigned it, I am quite
hesitant to changing the design again.

answer is to teach people a little bit about using honest-to-goodness
scripting languages when their applications reach this level of
complexity. How much daylight is there between needing script
variables and needing control flow, do you think?

Good question. It has been bothering me all along. The best answer to this
is probably an interactive interpreter of some procedural language we
offer. (I recall Oracle has their frontend that way.) Adding any more
complex functionality to psql will probably cripple it beyond recognition.
You can only go so far with hand-written parsers acting on poorly
specified rules consisting of tons of backslashes. :)

Anyway, good to see that all this "thinking big" might have had a point
after all.

-Peter

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

From bouncefilter Sat Nov 20 19:03:25 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA52435
for <pgsql-hackers@postgresql.org>;
Sat, 20 Nov 1999 19:03:22 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62266 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sBnP/141724>; Sun, 21 Nov 1999 01:03:13 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11p0hH-0000ck-00; Sat, 20 Nov 1999 03:56:19 +0100
Date: Sat, 20 Nov 1999 03:56:19 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] 7.0 status request
In-Reply-To: <199911190343.WAA23334@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.20.9911200344490.1512-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 1999-11-18, Bruce Momjian mentioned:

Here are the major open issues for 7.0 that I remember:

Does anyone ever plan on dropping any columns? I think this is a must-have
for the latest and greatest database system. I'm sure an experienced
backend hacker can put something together in a few days. If need be we
could just use a radical solution similar to cluster where you have to
shut down the whole database and rebuild all indices afterwards, but
pleeeeease.

Or this forgotten? Impossible? A feature?

Just wondering . . .

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

From bouncefilter Fri Nov 19 22:08:39 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA14952
for <hackers@postgreSQL.org>; Fri, 19 Nov 1999 22:08:30 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA23280;
Sat, 20 Nov 1999 03:08:48 GMT
Sender: lockhart@hub.org
Message-ID: <383610C0.F9BA9F1D@alumni.caltech.edu>
Date: Sat, 20 Nov 1999 03:08:48 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Eisentraut <peter_e@gmx.net>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] create/alter user extension syntax
References: <Pine.LNX.4.20.9911190103100.714-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I tried the following:
{CREATE|ALTER} USER username
[ WITH ID/UID/<whatever> number ]
[ WITH PASSWORD password ]
[ etc. as usual ]
which gives shift/reduce conflicts, even if I make PASSWORD and
ID/whatever a pure keyword (WITH is already one). So that won't work.

Sure it will (well, probably ;)

It depends how you set up the syntax. If you just try to have
something like (pseudocode, I'm rushing to leave for the weekend)

createuser: CREATE USER ColId Qual {};

Qual: WITH ID number {}
| WITH PASSWORD password {};

then the single-token lookahead of yacc will get in trouble. But if
you break it up some more then yacc can start maintaining multiple
token pointers to keep going, and the shift/reduce conflicts will go
away. Something like

cu: CREATE USER ColId QualClause {};

QualClause: QualClause WITH QualExpr {};
| QualClause {}
| /*EMPTY*/ {};

might do the trick, though I might be omitting one level. Check gram.y
for similar syntax examples such as the column qualifiers for CREATE
TABLE (though those are a bit more involved than this probably needs).

Good luck, and I'll be happy to help in a few days if you want.

- Thomas

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

From bouncefilter Fri Nov 19 22:20:39 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA16095
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 22:20:01 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA23286;
Sat, 20 Nov 1999 03:13:36 GMT
Sender: lockhart@hub.org
Message-ID: <383611E0.4B98FDFA@alumni.caltech.edu>
Date: Sat, 20 Nov 1999 03:13:36 +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: Lamar Owen <lamar.owen@wgcr.org>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] 7.0 status request
References: <3568.943049692@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Here are the major open issues for 7.0 that I remember:

I think Bruce was trying to list the work items that are both large
and fairly likely to be done before 7.0. (I suspect his motivation
is to figure out what changes he should allow for while writing his
book...)

Ah, that reminds me...

I will do a "type reunification" for the date/time types, hopefully by
the end of December. I consider this fairly important and have been
holding off for a major release to do it...

- Thomas

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

From bouncefilter Fri Nov 19 23:24:41 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 XAA22637
for <pgsql-hackers@postgreSQL.org>;
Fri, 19 Nov 1999 23:24:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id XAA03616
for pgsql-hackers@postgreSQL.org; Fri, 19 Nov 1999 23:23:13 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911200423.XAA03616@candle.pha.pa.us>
Subject: 7.0 status request
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Fri, 19 Nov 1999 23:23:13 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Current list is:

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

Outer Joins - Thomas?
Long Tuples - ?

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

I have another kind of problem related with MB and 6.5.3.

On FreeBSD 3.1:

[snip]

It's interesting that on Linux I have no problem.
I have no time right now to test 6.5.2 but I recall I had no
such problem (not 100% sure).

I think no change has been made between 6.5.2 and 6.5.3 regarding MB.
Can you send me the KOI8 data and WIN data that is supposed to be
correct? I will check it out on a FreeBSD 3.2 machine.

With PostgreSQL compiled with support for locales and multi-byte encoding:

initdb -e BIG5

No, you cannot do this. If you want to use traditional Chinese, you
have to make a database with EUC_TW (initdb -e EUC_TW) then set the
PGCLIENTENCODING environment variable to BIG5 on the client side. See
doc/README.mb for more details.

Maybe initdb should reject BIG5. I will do it in for the next release.
---
Tatsuo Ishii

From bouncefilter Sat Nov 20 08:28:18 1999
Received: from mhlx01.kek.jp (IDENT:pcs@mhlx01.kek.jp [130.87.225.230])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA88159
for <pgsql-hackers@postgresql.org>;
Sat, 20 Nov 1999 08:27:56 -0500 (EST)
(envelope-from pcs@mhlx01.kek.jp)
Received: (from pcs@localhost) by mhlx01.kek.jp (8.9.3/8.9.3) id WAA26644;
Sat, 20 Nov 1999 22:26:16 +0900
Date: Sat, 20 Nov 1999 22:26:16 +0900
From: "C.S.Park" <pcs@mhlx01.kek.jp>
To: pgsql-hackers@postgresql.org
Cc: "C.S.Park" <pcs@mhlx01.kek.jp>
Subject: [q] can I simply remove pg_log file?
Message-ID: <19991120222616.A26639@mhlx01.kek.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.4us

Hello all,

Due to the large objects in our database, it's not easy to
dump/reload. So if the 'pg_log' file becomes very big, can I
simply stop the server & delete it, and restart the server?
(w/o dump/reloading.) to save the disk space.

Best,
C.S.Park

From bouncefilter Sat Nov 20 11:05:19 1999
Received: from osprey.astro.umass.edu (root@osprey.astro.umass.edu
[128.119.51.182]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA05421
for <pgsql-hackers@postgreSQL.org>;
Sat, 20 Nov 1999 11:04:23 -0500 (EST)
(envelope-from weinberg@osprey.astro.umass.edu)
Received: (from weinberg@localhost)
by osprey.astro.umass.edu (8.9.3/8.9.3/Debian/GNU) id LAA25365;
Sat, 20 Nov 1999 11:04:23 -0500
Date: Sat, 20 Nov 1999 11:04:23 -0500
Message-Id: <199911201604.LAA25365@osprey.astro.umass.edu>
From: Martin Weinberg <weinberg@osprey.astro.umass.edu>
To: pgsql-hackers@postgreSQL.org
Cc: weinberg@osprey.astro.umass.edu
Subject: Bulk update of large database
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII

I have two tables of roughly 200,000,000 records and want
to update one column in one of the tables according to
values in the second table using a unique key.

For example:

update table1 set x=1 from table2 where
exists (select * from table2 table1.key=table2.key);

(or using an IN clause or using a straight join but EXPLAIN tells me
that the latter is much slower).

This does work but appends the updates (until the next vacuum).
For a 100GB database, this is too large of a storage overhead.
Is there another good way? I've searched the newsgroups, docs and
books without a clue . . .

Thanks much,

--Martin

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

Martin Weinberg Phone: (413) 545-3821
Dept. of Physics and Astronomy FAX: (413) 545-2117/0648
530 Graduate Research Tower weinberg@astro.umass.edu
University of Massachusetts http://www.astro.umass.edu/~weinberg/
Amherst, MA 01003-4525

From bouncefilter Sat Nov 20 12:26:20 1999
Received: from guard.polynet.lviv.ua (Guard.PolyNet.Lviv.UA [209.58.62.194])
by hub.org (8.9.3/8.9.3) with SMTP id MAA13341
for <pgsql-hackers@postgresql.org>;
Sat, 20 Nov 1999 12:25:50 -0500 (EST)
(envelope-from akorud@polynet.lviv.ua)
Received: (qmail 23774 invoked from network); 20 Nov 1999 17:25:43 -0000
Received: from unknown (HELO postoffice.polynet.lviv.ua) (unknown)
by unknown with SMTP; 20 Nov 1999 17:25:43 -0000
Received: (qmail 53628 invoked from network); 20 Nov 1999 17:25:43 -0000
Received: (ofmipd unknown); 20 Nov 1999 17:25:21 -0000
Date: 20 Nov 1999 19:25:42 +0200
Message-ID: <Pine.BSF.3.96.991120192202.53212A-100000@NetSurfer.lp.lviv.ua>
From: "Andrij Korud" <akorud@polynet.lviv.ua>
To: pgsql-hackers@postgresql.org
X-Sender: akorud@NetSurfer.lp.lviv.ua
Subject: C++ and SPI
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,
I'm trying to compile SPI function written on C++.
Compile fail on using C++ keywords (typeid, typename) in header files.
Wrapping #include in extern "C" {} don't help.
Here is output of the compiler:

++ -I/home/akorud/develop/postgresql-6.5.3/src/include
-I/usr/local/pgsql/include -traditional -o dialup.o -c dialup.cpp
In file included from
/home/akorud/develop/postgresql-6.5.3/src/include/nodes/relation.h:16,
                 from
/home/akorud/develop/postgresql-6.5.3/src/include/executor/spi.h:14,
                 from dialup.cpp:4:
/home/akorud/develop/postgresql-6.5.3/src/include/nodes/parsenodes.h:698:
parse error before `typename'
/home/akorud/develop/postgresql-6.5.3/src/include/nodes/parsenodes.h:738:
parse error before `typename'
/home/akorud/develop/postgresql-6.5.3/src/include/nodes/parsenodes.h:770:
parse error before `typename'
/home/akorud/develop/postgresql-6.5.3/src/include/nodes/parsenodes.h:874:
parse error before `;'
/home/akorud/develop/postgresql-6.5.3/src/include/nodes/parsenodes.h:875:
parse error before `typename'
In file included from
/home/akorud/develop/postgresql-6.5.3/src/include/utils/rel.h:17,
                 from
/home/akorud/develop/postgresql-6.5.3/src/include/access/relscan.h:17,
                 from
/home/akorud/develop/postgresql-6.5.3/src/include/nodes/execnodes.h:19,
                 from
/home/akorud/develop/postgresql-6.5.3/src/include/executor/spi.h:15,
                 from dialup.cpp:4:
/home/akorud/develop/postgresql-6.5.3/src/include/access/tupdesc.h:74:
parse error before `typeid'

Any suggestions?

Thanks in advance,
Andriy Korud, Lviv, Ukraine.

From bouncefilter Sat Nov 20 12:33:20 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA14031
for <pgsql-hackers@postgreSQL.org>;
Sat, 20 Nov 1999 12:33:19 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA07584;
Sat, 20 Nov 1999 12:32:16 -0500 (EST)
To: Martin Weinberg <weinberg@osprey.astro.umass.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Bulk update of large database
In-reply-to: Your message of Sat, 20 Nov 1999 11:04:23 -0500
<199911201604.LAA25365@osprey.astro.umass.edu>
Date: Sat, 20 Nov 1999 12:32:16 -0500
Message-ID: <7582.943119136@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Martin Weinberg <weinberg@osprey.astro.umass.edu> writes:

This does work but appends the updates (until the next vacuum).
For a 100GB database, this is too large of a storage overhead.
Is there another good way?

There is no alternative; any sort of update operation will write a
new tuple value without first deleting the old. This must be so
to preserve transaction semantics: if an error occurs later on
during the update (eg, violation of a unique-index constraint) the
old tuple value must still be there.

The only answer I can see is to update however many tuples you can
spare the space for, commit the transaction, vacuum, repeat.

The need for repeated vacuums in this scenario is pretty annoying.
It'd be nice if we could recycle dead tuples without a full vacuum.
Offhand I don't see any way to do it without introducing performance
penalties elsewhere...

regards, tom lane

From bouncefilter Sat Nov 20 16:45:24 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA38565
for <pgsql-hackers@postgreSQL.org>;
Sat, 20 Nov 1999 16:45:23 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id QAA27774
for <pgsql-hackers@postgreSQL.org>;
Sat, 20 Nov 1999 16:44:52 -0500 (EST)
To: hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] pg_dump bug
In-reply-to: Your message of Fri, 19 Nov 1999 10:07:44 -0500
<2349.943024064@sss.pgh.pa.us>
Date: Sat, 20 Nov 1999 16:44:52 -0500
Message-ID: <27772.943134292@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I wrote:

Current sources still have a problem with this example, which is that
the default expression gets prematurely constant-folded:
CREATE TABLE ut (d1 DATE DEFAULT CURRENT_DATE);
pg_dumps as
CREATE TABLE "ut" (
"d1" date DEFAULT '11-19-1999'::date);
Drat. I thought I'd taken care of that class of problems...

Fixed in CVS.

regards, tom lane

From bouncefilter Sat Nov 20 17:00:24 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA39920
for <pgsql-hackers@postgreSQL.org>;
Sat, 20 Nov 1999 16:59:44 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id QAA27844;
Sat, 20 Nov 1999 16:58:02 -0500 (EST)
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Subject: Re: [HACKERS] New regression driver
In-reply-to: Your message of Fri, 19 Nov 1999 20:30:14 +0100 (MET)
<m11otja-0003kKC@orion.SAPserv.Hamburg.dsh.de>
Date: Sat, 20 Nov 1999 16:58:01 -0500
Message-ID: <27842.943135081@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

wieck@debis.com (Jan Wieck) writes:

There is a new shell script run_check.sh in the regression
test directory. It is driven by the conficuration file
./sql/run_check.tests and runs most of our tests parallel. It
is invoked with the new GNUmakefile target 'runcheck'.

This is way cool. I had to fix a couple of silly little portability
problems, but I like it.

I think if my new test driver has settled, we should change
the GNUmakefile to just print some messages if 'make runtest'
is typed. The current runtest target should IMHO still be
availabe under another name, to test the real life
installation created by 'make install'.

Alternatively (IMHO better) some parameter to run_check.sh
could tell if it should create it's own, temporary
installation, or if it should use the existing installed
database system and the already running postmaster.

We should leave the old driver available, so that if an unexpected
problem arises one can easily check to see if it's being triggered by
concurrent execution or not. Or, run_check could have a parameter to
force serialized execution, if you would rather have just one script.
In that case we could toss the old runtest and rename run_check to
runtest. (If we do keep both scripts, can we pick more helpful names
than "runtest" and "run_check"? The difference is not immediately
obvious...)

I agree that run_check needs to be able to test a normal installation
as well as a temporary one.

Absolutely right and I've commented out that code for now.
It is in utils/cache/catcache.c line 996. The comments say
that the code should prevent the backend from entering
infinite recursion while loading new cache entries. But the
flag used for it seems to live in shared memory, thus it is
affected by other backends too. If the flag is true doesn't
tell if a backend set it itself, or if another one did. If we
really need this check, it must be implemented in another
way.

I will look at this. I don't think that the catcaches live in
shared memory, so the problem is probably not what you suggest.
The fact that the behavior is different under load may point to a
real problem, not just an insufficiently clever debugging check.

I ran the old regress.sh using the default installation
parallel to the run_check.sh using it's own installation and
postmaster.

They both give the same results on my platform, too.

regards, tom lane

From bouncefilter Sat Nov 20 15:03:22 1999
Received: from mail.hanarotel.net (mail.hananet.net [210.180.98.70])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA28651
for <pgsql-hackers@postgreSQL.org>;
Sat, 20 Nov 1999 15:02:24 -0500 (EST)
(envelope-from whyme@hananet.net)
Received: from whymeh ([210.205.16.166]) by mail.hanarotel.net
(Post.Office MTA v3.5.3 release 223
ID# 200-56547U100000L100000S0V35) with SMTP id net
for <pgsql-hackers@postgreSQL.org>; Sun, 21 Nov 1999 05:08:28 +0900
Message-ID: <01db01bf33a2$bddda000$a610cdd2@whymeh>
From: "Timothy" <whyme@hananet.net>
To: <pgsql-hackers@postgreSQL.org>
References: <1BF7C7482189D211B03F00805F8527F748C1FB@S-NATH-EXCH2>
Subject:
Date: Sun, 21 Nov 1999 07:01:04 +0900
MIME-Version: 1.0
Content-Type: text/plain;
charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6600
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by hub.org id PAA28686

Dear Sir.

I apolize for bothering you if this mail bothers you.
Would you mind if I ask you to introduce to me any excellent network hacker around you if you happen to have any information about this kind of matter?
Otherwise, may I ask you are willing to introduce your acquaintances who seems to well be informed about Institution Computer System Accessing? It is not harmful to anybody at all.
But I will pay for 20,000 dollars for his job. I say again it is not harmful at all. I just want to confirm why certain record missed.
I can make a business trip and meet him for details later.

Sincerely,

Timothy

From bouncefilter Sat Nov 20 19:11:25 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA53537
for <pgsql-hackers@postgreSQL.org>;
Sat, 20 Nov 1999 19:10:45 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id TAA07167;
Sat, 20 Nov 1999 19:10:10 -0500 (EST)
To: wieck@debis.com (Jan Wieck),
pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Subject: Re: [HACKERS] New regression driver
In-reply-to: Your message of Sat, 20 Nov 1999 16:58:01 -0500
<27842.943135081@sss.pgh.pa.us>
Date: Sat, 20 Nov 1999 19:10:09 -0500
Message-ID: <7165.943143009@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

wieck@debis.com (Jan Wieck) writes:

It is in utils/cache/catcache.c line 996. The comments say
that the code should prevent the backend from entering
infinite recursion while loading new cache entries.

I will look at this. I don't think that the catcaches live in
shared memory, so the problem is probably not what you suggest.
The fact that the behavior is different under load may point to a
real problem, not just an insufficiently clever debugging check.

Indeed, this is a real bug, and commenting out the code that caught
it is not the right fix!

What is happening is that utils/inval.c is trying to initialize some
variables that contain OIDs of system relations. This means calling
the catcache routines in order to look up relation names in pg_class.
However, if a shared cache inval message arrives from another backend
while that's happening, we recursively invoke inval.c to deal with the
message. And inval.c sees that its OID variables aren't initialized
yet, so it recursively calls the catcache routines to try to get them
initialized. Or, if just the first one's been initialized so far,
ValidateHacks() assumes they're all valid, and you can end up at the
elog(FATAL) panic at the bottom of CacheIdInvalidate(). I've got a core
dump which contains a ten-deep recursion between inval.c and syscache.c,
culminating in elog(FATAL) because the eleventh incoming sinval message
was just slow enough to let inval.c's first OID variable get filled in
before it arrived.

In short: we don't deal very robustly with cache invals happening
during backend startup. Send invals at a new backend with just the
right timing, and it'll choke.

I am not sure if this bug is of long standing or if we introduced it
since 6.5. It's possible I created it while messing with the relcache
stuff a month or two ago. But I can easily believe that it's been
there a long time and we never had a way of reproducing the problem
with any reliability before.

I think the fix is to rip out inval.c's attempt to look up system
relation names, and just give it hardwired knowledge of their OIDs.
Even though it sort-of works to do the lookups, it's bad practice for
routines that are potentially called during catcache initialization
to depend on the catcache to be already working. And there are other
places that already have hardwired knowledge of the system relation
OIDs, so...

regards, tom lane

From bouncefilter Sat Nov 20 20:04:25 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 UAA59715
for <pgsql-hackers@postgresql.org>;
Sat, 20 Nov 1999 20:04:02 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA20248;
Sat, 20 Nov 1999 19:55:03 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911210055.TAA20248@candle.pha.pa.us>
Subject: Re: [HACKERS] Getting OID in psql of recent insert
In-Reply-To: <Pine.LNX.4.20.9911200323100.1512-100000@localhost.localdomain>
from Peter Eisentraut at "Nov 20, 1999 03:38:35 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Sat, 20 Nov 1999 19:55:03 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset ISO-8859-1 unsupported, filtering to ASCII...]

On 1999-11-18, Tom Lane mentioned:

It'd certainly be easy enough for psql to save off the OID anytime it
gets an "INSERT nnn" command response. The missing link is to invent
a way for a psql script to access that value and insert it into
subsequent SQL commands.

Okay, I guess I'm way ahead of everyone here. It is in fact only a matter
of adding a few lines to save the oid in a variable, and all the
infrastructure for doing this is already present. In fact, I was going to
do this in the next few days.

testdb=> \set singlestep on
testdb=> \set sql_interpol '#'
testdb=> \set foo 'pg_class'
testdb=> select * from #foo#;
***(Single step mode: Verify query)**************
QUERY: select * from pg_class
***(press return to proceed or enter x and return to
cancel)********************
x
testdb=>

This is exactly what I was hoping you would say.

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

From bouncefilter Sat Nov 20 20:01:25 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA59533
for <pgsql-hackers@postgresql.org>;
Sat, 20 Nov 1999 20:01:02 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA20315;
Sat, 20 Nov 1999 19:58:16 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911210058.TAA20315@candle.pha.pa.us>
Subject: Re: [HACKERS] New regression driver
In-Reply-To: <7165.943143009@sss.pgh.pa.us> from Tom Lane at "Nov 20,
1999 07:10:09 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 20 Nov 1999 19:58:16 -0500 (EST)
CC: Jan Wieck <wieck@debis.com>,
PostgreSQL HACKERS <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I think the fix is to rip out inval.c's attempt to look up system
relation names, and just give it hardwired knowledge of their OIDs.
Even though it sort-of works to do the lookups, it's bad practice for
routines that are potentially called during catcache initialization
to depend on the catcache to be already working. And there are other
places that already have hardwired knowledge of the system relation
OIDs, so...

FYI, I am in the process of coding all cache miss lookups to use new
system indexes. I have also added code to SearchSelfReferences()
because pg_operator has some fancy depency on its lookup using an index,
and has to have certain lookup happen with an sequential and not an
index scan.

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

From bouncefilter Sat Nov 20 21:13:26 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA66577
for <pgsql-hackers@postgresql.org>;
Sat, 20 Nov 1999 21:12:35 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA23690;
Sat, 20 Nov 1999 21:11:48 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL HACKERS <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] New regression driver
In-reply-to: Your message of Sat, 20 Nov 1999 19:58:16 -0500 (EST)
<199911210058.TAA20315@candle.pha.pa.us>
Date: Sat, 20 Nov 1999 21:11:47 -0500
Message-ID: <23688.943150307@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

... I have also added code to SearchSelfReferences()
because pg_operator has some fancy depency on its lookup using an index,
and has to have certain lookup happen with an sequential and not an
index scan.

Say what? That's got to be a symptom of a bug somewhere. Maybe
pg_operator needs some CommandCounterIncrement calls so that the
tuples it inserts become visible earlier? What are you seeing exactly?

For that matter, SearchSelfReferences looks like one giant kluge to me.
Who added this, and why, and what's the logic? (Undocumented kluges
are very high on my hate list.)

regards, tom lane

From bouncefilter Sat Nov 20 21:39:26 1999
Received: from villa.bildbasen.se (villa.bildbasen.kiruna.se [193.45.225.97])
by hub.org (8.9.3/8.9.3) with SMTP id VAA69479
for <hackers@postgreSQL.org>; Sat, 20 Nov 1999 21:39:20 -0500 (EST)
(envelope-from goran@kirra.net)
Received: (qmail 18585 invoked from network); 21 Nov 1999 02:38:46 -0000
Received: from a103.dial.kiruna.se (HELO kirra.net) (193.45.238.3)
by villa.bildbasen.kiruna.se with SMTP; 21 Nov 1999 02:38:46 -0000
Sender: goran
Message-ID: <38375B2D.A2CEF372@kirra.net>
Date: Sun, 21 Nov 1999 03:38:37 +0100
From: Goran Thyni <goran@kirra.net>
Organization: kirra.net
X-Mailer: Mozilla 4.6 [en] (X11; U; Linux 2.2.13 i586)
X-Accept-Language: sv, en
MIME-Version: 1.0
To: PostgreSQL-development <hackers@postgreSQL.org>,
The Hermit Hacker <scrappy@hub.org>
Subject: Advogato
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Marc (et al),

There is a new community web site at:

http://advogato.org/

A goal is to find common ground between projects.
The easy way for many projects has been to
use a not-really-a-RDBMS-engine.
It would be a good thing for pgsql-core to get
involved to get more support for our engine
in various free software projects.

regards,
G�ran

From bouncefilter Sun Nov 21 14:48:38 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 OAA77068
for <pgsql-hackers@postgreSQL.org>;
Sun, 21 Nov 1999 14:47:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id OAA05943
for <pgsql-hackers@postgreSQL.org>;
Sun, 21 Nov 1999 14:47:06 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: locking needed for parsing & planning
Date: Sun, 21 Nov 1999 14:47:06 -0500
Message-ID: <5938.943213626@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I have been investigating Oleg's report of backend crashes induced by
drop index/vacuum/create index in parallel with table updates. The
problem is pretty simple: there's not enough of an interlock between
DROP INDEX and normal activities on tables. In particular, it's
entirely possible for DROP INDEX to drop an index that someone else
is busy scanning or adding entries to :-(

I find that things get a *lot* more stable if DROP INDEX grabs an
exclusive lock on the parent table, not just on the target index.
That prevents the DROP from occurring while someone is actively
scanning or updating the index as part of a query on the parent
table. However, I still get infrequent complaints like
ERROR: IndexSelectivity: index 292801 not found
The reason for that is that the parser and planner don't have any
kind of lock on the tables they are working with --- we don't grab
locks until the executor starts. So, the planner can look around
for indexes for the tables in the query, find some, and then discover
that the indexes have gone away when it tries to do something with them.

I was thinking about solving this by moving lock-acquisition out of
the executor and up to the start of the planning process; if we have
some kind of lock on every table mentioned in the query, we can be
sure that DROP INDEX won't be able to remove any indexes that we are
working with in the planner.

However, that doesn't completely eliminate this class of problems,
because the parser and rewriter are still exposed. They don't care
about indexes, but they do care about table definitions. For example,
"SELECT * FROM table" could generate an obsolete expansion for "*"
if an ALTER TABLE ADD/DROP/RENAME COLUMN commits after parsing starts.

Grabbing locks in the parser doesn't seem like a hot idea, mainly
because the parser doesn't have full information --- it has no idea what
will happen downstream in the rewriter. If the parser grabs a read-type
lock on some table, and then a rewrite rule requires us to get a
stronger lock on that table, then we've just created a potential for
deadlock against some other backend. So I'm not sure there is any cure
that's not worse than the disease for the parser. (Most of the bad
scenarios here require ALTER TABLE functionality that we don't have
anyway.)

I have no idea what can go wrong in the rewriter if tables are being
altered underneath it, nor whether it's practical to grab locks to
prevent that. Jan, at what point can we be sure we know the type
of lock needed for each table used in a query? The planner has
complete info when it starts, but can the rewriter know this before
it's too late?

I'm going to commit the change to make DROP INDEX lock the parent table,
but I wanted to see if anyone has any comments or better ideas about
obtaining execution locks in the planner instead of the executor...

regards, tom lane

From bouncefilter Sun Nov 21 18:01: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 SAA00521
for <pgsql-hackers@postgreSQL.org>;
Sun, 21 Nov 1999 18:01:04 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA10171
for <pgsql-hackers@postgreSQL.org>;
Sun, 21 Nov 1999 18:00:29 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Reproducible vacuum complaint!
Date: Sun, 21 Nov 1999 18:00:29 -0500
Message-ID: <10168.943225229@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I have devised a simple manual way of reproducing that peculiar VACUUM
notice that Oleg has been complaining about, but didn't have a reliable
way of triggering on-demand. It looks like it is caused by some sort of
bug in the transaction commit logic --- or maybe just VACUUM's piece of
it, but anyway there is something mucho bad going on here.

Setup:

create table hits (msg_id int, nhits int);
create index hits_pkey on hits(msg_id);
insert into hits values(42,0);
insert into hits values(43,0);

Given this setup, you can do

drop index hits_pkey;
update hits set nhits = nhits+1 where msg_id = 42;
create index hits_pkey on hits(msg_id);
vacuum analyze hits;

all day with no problem.

BUT: start up another psql, and in that other psql begin a transaction
block and touch anything at all --- doesn't have to be the table under
test:

begin;
select * from int4_tbl;

Now, *without committing* that other transaction, go back to the first
psql and try again:

drop index hits_pkey;
update hits set nhits = nhits+1 where msg_id = 42;
create index hits_pkey on hits(msg_id);
vacuum analyze hits;
NOTICE: Index hits_pkey: NUMBER OF INDEX' TUPLES (2) IS NOT THE SAME AS HEAP' (3).
Try recreating the index.

You can repeat the vacuum (with or without analyze) as often as you want
and you'll get the same notice each time. If you do more UPDATEs, the
reported number of heap tuples increases --- rather odd, considering
there are obviously only two committed tuples in the table (as can be
confirmed by a SELECT).

As soon as you commit or abort the other transaction, everything goes
back to normal.

There are variants of this sequence that also cause the problem. The
critical factor seems to be that both the index itself and at least one
tuple in the table have to be younger than the oldest uncommitted
transaction.

At this point I decided that I was in over my head, so I'm tossing the
whole mess in Vadim's direction. I can't tell whether VACUUM itself
is confused or the transaction logic in general is, but it sure looks
like something is looking at the wrong xact to decide whether tuples
have been committed or not. This could be a symptom of a fairly serious
logic error down inside tuple time qual checks...

regards, tom lane

From bouncefilter Sun Nov 21 19:26:41 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 TAA40747
for <pgsql-hackers@postgreSQL.org>;
Sun, 21 Nov 1999 19:26:15 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA02117; Mon, 22 Nov 1999 09:24:42 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Reproducible vacuum complaint!
Date: Mon, 22 Nov 1999 09:29:17 +0900
Message-ID: <000201bf3480$9c2fcda0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <10168.943225229@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
Sent: Monday, November 22, 1999 8:00 AM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] Reproducible vacuum complaint!

I have devised a simple manual way of reproducing that peculiar VACUUM
notice that Oleg has been complaining about, but didn't have a reliable
way of triggering on-demand. It looks like it is caused by some sort of
bug in the transaction commit logic --- or maybe just VACUUM's piece of
it, but anyway there is something mucho bad going on here.

Setup:

create table hits (msg_id int, nhits int);
create index hits_pkey on hits(msg_id);
insert into hits values(42,0);
insert into hits values(43,0);

Given this setup, you can do

drop index hits_pkey;
update hits set nhits = nhits+1 where msg_id = 42;
create index hits_pkey on hits(msg_id);
vacuum analyze hits;

all day with no problem.

BUT: start up another psql, and in that other psql begin a transaction
block and touch anything at all --- doesn't have to be the table under
test:

begin;
select * from int4_tbl;

Now, *without committing* that other transaction, go back to the first
psql and try again:

drop index hits_pkey;
update hits set nhits = nhits+1 where msg_id = 42;
create index hits_pkey on hits(msg_id);
vacuum analyze hits;
NOTICE: Index hits_pkey: NUMBER OF INDEX' TUPLES (2) IS NOT THE
SAME AS HEAP' (3).
Try recreating the index.

Hmm,if "select * .." runs in SERIALIZABLE isolation level,the transaction
would see an old "msg_id=42" tuple(not new one). So vacuum doesn't
vanish the old "msg_id=42" tuple. Vacuum takes all running transactions
into account. But AFAIK,there's no other such stuff.
CREATE INDEX may be another one which should take all running
transactions into account.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Nov 21 21:38:43 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 VAA56127
for <pgsql-hackers@postgreSQL.org>;
Sun, 21 Nov 1999 21:37:58 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id LAA02177; Mon, 22 Nov 1999 11:35:51 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "PostgreSQL HACKERS" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] New regression driver
Date: Mon, 22 Nov 1999 11:40:26 +0900
Message-ID: <000201bf3492$eeadcb60$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <23688.943150307@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
Sent: Sunday, November 21, 1999 11:12 AM
To: Bruce Momjian
Cc: PostgreSQL HACKERS
Subject: Re: [HACKERS] New regression driver

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

... I have also added code to SearchSelfReferences()
because pg_operator has some fancy depency on its lookup using an index,
and has to have certain lookup happen with an sequential and not an
index scan.

Say what? That's got to be a symptom of a bug somewhere. Maybe
pg_operator needs some CommandCounterIncrement calls so that the
tuples it inserts become visible earlier? What are you seeing exactly?

For that matter, SearchSelfReferences looks like one giant kluge to me.
Who added this, and why, and what's the logic? (Undocumented kluges
are very high on my hate list.)

It's me who added the function.
I left it undocumented,sorry.
Bruce,could you add an document on it ?

Bruce added a new index to pg_index.
Index scan needs an information of pg_index.
If we use the new index,we needs the information about the index
in pg_index.
Doesn't this cause a real cycle ?

I added the function in order to hold one tuple which causes a real
cycle. The tuple in pg_index should be scanned sequentially.

I don't think it's the best solution.
Please change it if there's a better way.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Nov 21 21:50:43 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA57905
for <pgsql-hackers@postgreSQL.org>;
Sun, 21 Nov 1999 21:49:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA22372;
Sun, 21 Nov 1999 21:46:45 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911220246.VAA22372@candle.pha.pa.us>
Subject: Re: [HACKERS] New regression driver
In-Reply-To: <000201bf3492$eeadcb60$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Nov 22, 1999 11:40:26 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Sun, 21 Nov 1999 21:46:45 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

It's me who added the function.
I left it undocumented,sorry.
Bruce,could you add an document on it ?

Done. Will commit soon.

Bruce added a new index to pg_index.
Index scan needs an information of pg_index.
If we use the new index,we needs the information about the index
in pg_index.
Doesn't this cause a real cycle ?

Yes. I am using it for a pg_operator index too.

I added the function in order to hold one tuple which causes a real
cycle. The tuple in pg_index should be scanned sequentially.

I don't think it's the best solution.
Please change it if there's a better way.

I talked to Tom, and we think it is a good solution.

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

From bouncefilter Sun Nov 21 23:12: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 XAA67186
for <pgsql-hackers@postgreSQL.org>;
Sun, 21 Nov 1999 23:11:50 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA21021;
Sun, 21 Nov 1999 23:11:10 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Reproducible vacuum complaint!
In-reply-to: Your message of Mon, 22 Nov 1999 09:29:17 +0900
<000201bf3480$9c2fcda0$2801007e@cadzone.tpf.co.jp>
Date: Sun, 21 Nov 1999 23:11:10 -0500
Message-ID: <21019.943243870@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Hmm,if "select * .." runs in SERIALIZABLE isolation level,the transaction
would see an old "msg_id=42" tuple(not new one). So vacuum doesn't
vanish the old "msg_id=42" tuple. Vacuum takes all running transactions
into account. But AFAIK,there's no other such stuff.
CREATE INDEX may be another one which should take all running
transactions into account.

Oh, I think I see --- you mean that CREATE INDEX needs to make index
entries for tuples that are committed dead but might still be visible
to some running transaction somewhere. Yes, that seems to fit what
I was seeing. VACUUM always complained that there were too few
index entries, never too many.

It looks like btbuild() only indexes tuples that satisfy SnapshotNow,
so this is definitely a potential problem for btree indexes. The other
index types are likely broken in the same way...

Comments anyone? What time qual should btbuild and friends be using,
if not that?

regards, tom lane

From bouncefilter Mon Nov 22 00:19: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 AAA82117
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 00:19:31 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id MAA20787;
Mon, 22 Nov 1999 12:19:12 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <3838D24F.DB274049@krs.ru>
Date: Mon, 22 Nov 1999 12:19:11 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Reproducible vacuum complaint!
References: <21019.943243870@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

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

Hmm,if "select * .." runs in SERIALIZABLE isolation level,the transaction
would see an old "msg_id=42" tuple(not new one). So vacuum doesn't
vanish the old "msg_id=42" tuple. Vacuum takes all running transactions
into account. But AFAIK,there's no other such stuff.
CREATE INDEX may be another one which should take all running
transactions into account.

...

It looks like btbuild() only indexes tuples that satisfy SnapshotNow,
so this is definitely a potential problem for btree indexes. The other
index types are likely broken in the same way...

Comments anyone? What time qual should btbuild and friends be using,
if not that?

Seems that we need in new

#define SnapshotAny ((Snapshot) 0x2)

and new HeapTupleSatisfiesAny() returning TRUE for any tuple
with valid and committed (or current xact id) t_xmin.

-:(

Sorry, I missed CREATE INDEX case.

Vadim
P.S. I'll comment about indices and vacuum latter...

From bouncefilter Mon Nov 22 01:40: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 BAA90616
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 01:40:31 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id BAA18140
for pgsql-hackers@postgreSQL.org; Mon, 22 Nov 1999 01:33:55 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911220633.BAA18140@candle.pha.pa.us>
Subject: cache question
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 22 Nov 1999 01:33:55 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can someone explain why there are two network_ops in the pg_opclass
table? I am trying to make pg_opclass unique. We have a cache on
pg_opclass.opcname, so we clearly have a problem here.

Also, is it safe to set opcdeftype to a non-zero value so I can make
that index unique too?

This stuff confusing.

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

From bouncefilter Mon Nov 22 02:01:54 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 CAA92754
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 02:00:55 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA20356;
Mon, 22 Nov 1999 01:50:50 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911220650.BAA20356@candle.pha.pa.us>
Subject: Re: [HACKERS] cache question
In-Reply-To: <199911220633.BAA18140@candle.pha.pa.us> from Bruce Momjian at
"Nov 22, 1999 01:33:55 am"
To: Bruce Momjian <pgman@candle.pha.pa.us>
Date: Mon, 22 Nov 1999 01:50:50 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can someone explain why there are two network_ops in the pg_opclass
table? I am trying to make pg_opclass unique. We have a cache on
pg_opclass.opcname, so we clearly have a problem here.

Also, is it safe to set opcdeftype to a non-zero value so I can make
that index unique too?

This stuff confusing.

Looks like I fixed it. I made on inet_ops and the other cidr_ops.
Those names should be unique in there anyway. They are just used when
specifying the ops on an index create. The zero entries I just set to
dummy values for int24 and int42 because there are no type that match
them. I set their typedef to be the same as the ops oid. Hope the
sanity check doesn't complain.

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

From bouncefilter Mon Nov 22 02:04:49 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA92955
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 02:04:14 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id CAA21494;
Mon, 22 Nov 1999 02:02:44 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] cache question
In-reply-to: Your message of Mon, 22 Nov 1999 01:33:55 -0500 (EST)
<199911220633.BAA18140@candle.pha.pa.us>
Date: Mon, 22 Nov 1999 02:02:43 -0500
Message-ID: <21492.943254163@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Can someone explain why there are two network_ops in the pg_opclass
table?

Looks like one is for type inet and the other for type cidr. I'm
still confused about the difference between the two types (hey,
I ain't Paul Vixie) but I suspect we don't really need two entries
in pg_opclass for them --- the types are binary-equivalent according
to parse_coerce.h. If we do need two entries, they should be given
different names.

This stuff confusing.

It's 1:30AM EST ... way past time to be doing serious work, at least
in this time zone ...

regards, tom lane

From bouncefilter Mon Nov 22 10:20:56 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA75571
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 10:19:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
KAA08635;
Mon, 22 Nov 1999 10:17:19 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911221517.KAA08635@candle.pha.pa.us>
Subject: Re: [HACKERS] cache question
In-Reply-To: <21492.943254163@sss.pgh.pa.us> from Tom Lane at "Nov 22,
1999 02:02:43 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 22 Nov 1999 10:17:19 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Can someone explain why there are two network_ops in the pg_opclass
table?

Looks like one is for type inet and the other for type cidr. I'm
still confused about the difference between the two types (hey,
I ain't Paul Vixie) but I suspect we don't really need two entries
in pg_opclass for them --- the types are binary-equivalent according
to parse_coerce.h. If we do need two entries, they should be given
different names.

Done. That's how I did it.

This stuff confusing.

It's 1:30AM EST ... way past time to be doing serious work, at least
in this time zone ...

Yes, I wanted to get it working. Seems like it works now. Will commit
soon.

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

From bouncefilter Mon Nov 22 11:01:52 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA98876
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 11:01:43 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA24625;
Mon, 22 Nov 1999 11:00:11 -0500 (EST)
To: pgman@candle.pha.pa.us
cc: pgsql-hackers@postgreSQL.org
Subject: TODO updates
Date: Mon, 22 Nov 1999 11:00:11 -0500
Message-ID: <24622.943286411@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

The following TODO items seem to be taken care of in current sources,
but aren't marked done in TODO:

PARSER

* INSERT INTO ... SELECT with AS columns matching result columns problem
* UNION with LIMIT fails
* CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
* CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
* mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
* SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes

URGENT

* Eliminate limits on query length

(Not quite done, but close enough to put a dash on it...)

TYPES

* Allow compression of large fields or a compressed field type

Jan just created a compressed text type, so this is partly done.
We speculated a little about adding a lower-level mechanism that would
compress whole tuples, so maybe this item should be replaced by one
mentioning that idea (it wouldn't belong in the TYPES section though).

MISC

* Allow subqueries in target list

* Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup

Is this one done, or do we still have issues there? I think it's a lot
better than it used to be, anyway...

SOURCE CODE

* Make configure --enable-debug add -g on compile line

regards, tom lane

From bouncefilter Mon Nov 22 11:07:52 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 LAA99696
for <hackers@postgreSQL.org>; Mon, 22 Nov 1999 11:07:29 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id RAA210632
for <hackers@postgreSQL.org>; Mon, 22 Nov 1999 17:07:25 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQSWW>; Mon, 22 Nov 1999 17:07:24 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC17F@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'hackers@postgreSQL.org'" <hackers@postgreSQL.org>
Subject: AW: [HACKERS] psql & regress tests
Date: Mon, 22 Nov 1999 17:07:14 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

* Since no one has picked up on my idea to run the tests

directly on the

backend, I will keep reiterating this idea until someone shuts me up
:*) The idea would be to have a target "check" in the top

level makefile

like this (conceptually):

Running the backend standalone does not use locking with
other backends,
so it is dangerous.

Well, he is talking about a newly created database that resides in the build

directory tree, so this is not of concern, since it is nowhere that any
other backend
can connect to.

My concern would rather be, that you would not be testing the locking, exev
....
Is it possible to start one backend in the same way postmaster would start
it ?

Andreas

From bouncefilter Mon Nov 22 11:28: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 LAA03283
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 11:28:20 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id RAA87432
for <pgsql-hackers@postgreSQL.org>; Mon, 22 Nov 1999 17:28:18 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQS5F>; Mon, 22 Nov 1999 17:28:18 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC180@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Getting OID in psql of recent insert
Date: Mon, 22 Nov 1999 17:28:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

once inserted, a row keeps its oid. so, when performing complex
selects, i'll often grab the oid too... do some tests on

the returned

values, and if an action is appropriate on that row, i

reference it by

its oid. the only chance of this failing is if the

database is dumped

then restored between the select and the update (not gonna

happen, as

the program requires the database available for execution)... using
the oid this way, its often simpler and faster to update a

known row,

especially when the initial select involved many fields.

Yes, I use 'em the same way. I think an OID is kind of like a pointer
in a C program: good for fast, unique access to an object within the
context of the execution of a particular application (and maybe not
even that long). You don't write pointers into files to be used again
by other programs, though, and in the same way an OID isn't a good
candidate for a long-lasting reference from one table to another.

regards, tom lane

I thought this special case is where the new xid access method would come
in.
It is actually a lot faster than oid access, since it marks the physical
position
that would otherwise need to be looked up in the oid index. This same oid
index
would also add unneeded overhead to the inserts and updates.

Is someone still working on the xid access ?

Andreas

From bouncefilter Mon Nov 22 11:40:53 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 LAA05340
for <pgsql-hackers@postgresql.org>;
Mon, 22 Nov 1999 11:40:18 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id LAA27462
for <pgsql-hackers@postgresql.org>; Mon, 22 Nov 1999 11:40:23 -0500
Message-ID: <383971F1.D7F2DB03@wgcr.org>
Date: Mon, 22 Nov 1999 11:40:17 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Re: postgres RPM build on Suse linux 6.2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[I've been working with Jef Peeraer on building the RPM's on SuSE Linux,
and ran across what I think is an autoconf issue. The configure script
complained that it couldn't find the tk config script
(/usr/lib/tkConfig.sh on most tk installs), which botched the whole
build in an obscure place.]

Subject : postgres RPM build on a Suse 6.2 machine.
Tk is installed, but it is maybe the location that matters :
/usr/X11R6/lib/tkConfig.sh.
Is a part of this path hard coded somewhere ? ( auto-configure ).

Bruce, I seem to recall that the PATH_TO_WISH issue with pgaccess
prompted some autoconf stuff -- is this related?

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

From bouncefilter Mon Nov 22 12:07: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 MAA21484
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 12:07:13 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id SAA192696;
Mon, 22 Nov 1999 18:06:51 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQS93>; Mon, 22 Nov 1999 18:06:51 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC181@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'Peter Eisentraut'" <peter_e@gmx.net>
Cc: "'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Getting OID in psql of recent insert
Date: Mon, 22 Nov 1999 18:06:46 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

testdb=> \set singlestep on
testdb=> \set sql_interpol '#'
testdb=> \set foo 'pg_class'
testdb=> select * from #foo#;

This is great, but may I object to the syntax ?
The standard sql way to use host variables seems to be:
select * from :foo where id = :id

There will always be the problem with conflicting operators,
and this one syntax, already needed by ecpg, it is hard enough.

Andreas

From bouncefilter Mon Nov 22 12:48:54 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA26736
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 12:48:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA04455;
Mon, 22 Nov 1999 12:47:26 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911221747.MAA04455@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: postgres RPM build on Suse linux 6.2
In-Reply-To: <383971F1.D7F2DB03@wgcr.org> from Lamar Owen at "Nov 22,
1999 11:40:17 am"
To: Lamar Owen <lamar.owen@wgcr.org>
Date: Mon, 22 Nov 1999 12:47:26 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[I've been working with Jef Peeraer on building the RPM's on SuSE Linux,
and ran across what I think is an autoconf issue. The configure script
complained that it couldn't find the tk config script
(/usr/lib/tkConfig.sh on most tk installs), which botched the whole
build in an obscure place.]

Subject : postgres RPM build on a Suse 6.2 machine.
Tk is installed, but it is maybe the location that matters :
/usr/X11R6/lib/tkConfig.sh.
Is a part of this path hard coded somewhere ? ( auto-configure ).

Bruce, I seem to recall that the PATH_TO_WISH issue with pgaccess
prompted some autoconf stuff -- is this related?

Not related, I think. PATH_TO_WISH is just set to @WISH@ in the actual
executable. I never touched the tkConfig stuff.

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

From bouncefilter Mon Nov 22 12:48:53 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA26739
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 12:48:44 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA04487;
Mon, 22 Nov 1999 12:47:47 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911221747.MAA04487@candle.pha.pa.us>
Subject: Re: AW: [HACKERS] Getting OID in psql of recent insert
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC181@sdexcsrv1.f000.d0188.sd.spardat.at>
from Zeugswetter Andreas SEV at "Nov 22, 1999 06:06:46 pm"
To: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
Date: Mon, 22 Nov 1999 12:47:47 -0500 (EST)
CC: "'Peter Eisentraut'" <peter_e@gmx.net>,
"'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

testdb=> \set singlestep on
testdb=> \set sql_interpol '#'
testdb=> \set foo 'pg_class'
testdb=> select * from #foo#;

This is great, but may I object to the syntax ?
The standard sql way to use host variables seems to be:
select * from :foo where id = :id

There will always be the problem with conflicting operators,
and this one syntax, already needed by ecpg, it is hard enough.

Agreed.

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

From bouncefilter Mon Nov 22 13:00:54 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA28886
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 12:59:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id MAA05297
for pgsql-hackers@postgreSQL.org; Mon, 22 Nov 1999 12:59:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911221759.MAA05297@candle.pha.pa.us>
Subject: System cache index cleanup
To: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Date: Mon, 22 Nov 1999 12:59:25 -0500 (EST)
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have made most system indexes unique.

I have added indexes to match all system caches.

I have renamed some cache names to be clearer.

I have re-ordered the cache entries to be alphabetical.

I have renamed the inheritance *rel columns to be *relid.

I have added a large comment to syscache.c listing steps needed to
install a new system index.

I saw no speed improvement from my changes, but I can imagine cases
where this would be a speedup.

The only thing missing is that I can't seem to get pg_shadow to use an
index from the cache. When I try it, initdb runs really slow, and the
resulting installation is unusable. Any ideas anyone? You can see my
commented-out code in indexing.c and syscache.c. My guess is that the
strange way we issue pg_exec_query_dest() calls is the cause. I have no
call to CatalogIndexInsert() for the pg_shadow because of this. Anyone
want to rewrite user.c to use heap_insert() instead.

initdb required.

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

From bouncefilter Mon Nov 22 13:04:54 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA29922
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 13:04:36 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA06011;
Mon, 22 Nov 1999 13:03:39 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911221803.NAA06011@candle.pha.pa.us>
Subject: Re: TODO updates
In-Reply-To: <24622.943286411@sss.pgh.pa.us> from Tom Lane at "Nov 22,
1999 11:00:11 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 22 Nov 1999 13:03:39 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

The following TODO items seem to be taken care of in current sources,
but aren't marked done in TODO:

Thanks. I have trouble figuring out which fixes I hear about go with
which items. I also forget they are on there.

PARSER

* INSERT INTO ... SELECT with AS columns matching result columns problem
* UNION with LIMIT fails
* CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
* CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
* mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
* SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes

Thanks. Done.

URGENT

* Eliminate limits on query length

(Not quite done, but close enough to put a dash on it...)

Marked.

TYPES

* Allow compression of large fields or a compressed field type

Jan just created a compressed text type, so this is partly done.
We speculated a little about adding a lower-level mechanism that would
compress whole tuples, so maybe this item should be replaced by one
mentioning that idea (it wouldn't belong in the TYPES section though).

Marked. Let someone ask for tuple compression.

MISC

* Allow subqueries in target list

Marked.

* Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup

Is this one done, or do we still have issues there? I think it's a lot
better than it used to be, anyway...

Marked.

SOURCE CODE

* Make configure --enable-debug add -g on compile line

Marked.

Thanks. Updated.

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

From bouncefilter Mon Nov 22 13:38:54 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 NAA35531
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 13:37:59 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id NAA27706;
Mon, 22 Nov 1999 13:37:46 -0500
Message-ID: <38398D73.8D466F32@wgcr.org>
Date: Mon, 22 Nov 1999 13:37:39 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: postgres RPM build on Suse linux 6.2
References: <199911221747.MAA04455@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Bruce, I seem to recall that the PATH_TO_WISH issue with pgaccess
prompted some autoconf stuff -- is this related?

Not related, I think. PATH_TO_WISH is just set to @WISH@ in the actual
executable. I never touched the tkConfig stuff.

Ok. I'm going to have to do some digging -- there are a multitude of
other X11-related configure shenanigans I'm going to have to take care
of for building the RPMs on SuSE. I eventually hope to have it where
people can rebuild the RPM set with a simple 'rpm --rebuild' instead of
what some are having to do now. On RedHat Intel, Sparc, or Alpha, the
--rebuild is enough -- but RedHat is not the only RPM-based distribution
(nor is linux the only OS that can have RPM installed....). Time to buy
CheapBytes' Mondo CD pack (five linux distributions on CD)....

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

From bouncefilter Mon Nov 22 14:11:54 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA39778
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 14:11:36 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id OAA25217;
Mon, 22 Nov 1999 14:10:49 -0500 (EST)
To: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
cc: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] Getting OID in psql of recent insert
In-reply-to: Your message of Mon, 22 Nov 1999 17:28:11 +0100
<219F68D65015D011A8E000006F8590C603FDC180@sdexcsrv1.f000.d0188.sd.spardat.at>
Date: Mon, 22 Nov 1999 14:10:49 -0500
Message-ID: <25215.943297849@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at> writes:

Yes, I use 'em the same way. I think an OID is kind of like a pointer
in a C program: good for fast, unique access to an object within the
context of the execution of a particular application (and maybe not
even that long). You don't write pointers into files to be used again
by other programs, though, and in the same way an OID isn't a good
candidate for a long-lasting reference from one table to another.

I thought this special case is where the new xid access method would come
in.

Good point, but (AFAIK) you could only use it for tables that you were
sure no other client was updating in parallel. Otherwise you might be
updating a just-obsoleted tuple. Or is there a solution for that?

Is someone still working on the xid access ?

I think we have the ability to refer to CTID in WHERE now, but not yet an
access method that actually makes it fast...

regards, tom lane

From bouncefilter Mon Nov 22 14:16:54 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA40648
for <pgsql-hackers@postgresql.org>;
Mon, 22 Nov 1999 14:16:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id OAA25235;
Mon, 22 Nov 1999 14:15:39 -0500 (EST)
To: Lamar Owen <lamar.owen@wgcr.org>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: postgres RPM build on Suse linux 6.2
In-reply-to: Your message of Mon, 22 Nov 1999 11:40:17 -0500
<383971F1.D7F2DB03@wgcr.org>
Date: Mon, 22 Nov 1999 14:15:39 -0500
Message-ID: <25233.943298139@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

[I've been working with Jef Peeraer on building the RPM's on SuSE Linux,
and ran across what I think is an autoconf issue. The configure script
complained that it couldn't find the tk config script
(/usr/lib/tkConfig.sh on most tk installs), which botched the whole
build in an obscure place.]

--with-tclconfig and/or --with-tkconfig should fix this. I forget
whether those are in 6.5.* though.

Since we also look for "wish" in the PATH, it would be nice if we could
ask wish where the tcl/tk config files are, instead of having to search
for them ourselves. But AFAIK you can't fire up a wish without having
an X display for it to connect to ... and configure can't assume that.

regards, tom lane

From bouncefilter Mon Nov 22 15:33:55 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA60735
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 15:33:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA09122;
Mon, 22 Nov 1999 14:37:54 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911221937.OAA09122@candle.pha.pa.us>
Subject: Re: AW: [HACKERS] Getting OID in psql of recent insert
In-Reply-To: <25215.943297849@sss.pgh.pa.us> from Tom Lane at "Nov 22,
1999 02:10:49 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 22 Nov 1999 14:37:54 -0500 (EST)
CC: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>,
"'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at> writes:

Yes, I use 'em the same way. I think an OID is kind of like a pointer
in a C program: good for fast, unique access to an object within the
context of the execution of a particular application (and maybe not
even that long). You don't write pointers into files to be used again
by other programs, though, and in the same way an OID isn't a good
candidate for a long-lasting reference from one table to another.

I thought this special case is where the new xid access method would come
in.

Good point, but (AFAIK) you could only use it for tables that you were
sure no other client was updating in parallel. Otherwise you might be
updating a just-obsoleted tuple. Or is there a solution for that?

Is someone still working on the xid access ?

I think we have the ability to refer to CTID in WHERE now, but not yet an
access method that actually makes it fast...

Hiroshi supplied a patch to allow it in the executor, and I applied it.

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

From bouncefilter Tue Nov 23 03:13:03 1999
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA64362
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 03:12:54 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9C1449.dip0.t-ipconnect.de
(root@p3E9C1449.dip0.t-ipconnect.de [62.156.20.73])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id JAA50797
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 09:06:48 +0100 (CET)
(envelope-from michael@fam-meskes.de)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id WAA01913
for pgsql-hackers@postgresql.org; Mon, 22 Nov 1999 22:06:16 +0100
Date: Mon, 22 Nov 1999 22:06:16 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: Float/Numeric?
Message-ID: <19991122220616.A1895@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i

Could anyone tell me why the following does not work without a cast?

mm=> select * from test;
f|i|a
------+-+---------------------
404.90|1|{0,1,2,3,4,5,6,7,8,9}
(1 row)

mm=> select i from test where f=404.90
mm-> ;
ERROR: Unable to identify an operator '=' for types 'numeric' and 'float8'
You will have to retype this query using an explicit cast
mm=> select i from test where f::float=404.90;
i
-
1
(1 row)

Shouldn't there be an implicit cast between numeric and float?

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Mon Nov 22 16:11:56 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id QAA66003
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 16:11:31 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 21130 invoked by uid 1001); 22 Nov 1999 21:11:34 -0000
Message-ID: <XFMail.991122161134.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <25233.943298139@sss.pgh.pa.us>
Date: Mon, 22 Nov 1999 16:11:34 -0500 (EST)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] Re: postgres RPM build on Suse linux 6.2
Cc: pgsql-hackers@postgreSQL.org, Lamar Owen <lamar.owen@wgcr.org>

On 22-Nov-99 Tom Lane wrote:

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

[I've been working with Jef Peeraer on building the RPM's on SuSE Linux,
and ran across what I think is an autoconf issue. The configure script
complained that it couldn't find the tk config script
(/usr/lib/tkConfig.sh on most tk installs), which botched the whole
build in an obscure place.]

--with-tclconfig and/or --with-tkconfig should fix this. I forget
whether those are in 6.5.* though.

Since we also look for "wish" in the PATH, it would be nice if we could
ask wish where the tcl/tk config files are, instead of having to search
for them ourselves. But AFAIK you can't fire up a wish without having
an X display for it to connect to ... and configure can't assume that.

I added --with-tkconfig somewhere around March 4, 1999. That's the date
on my patch file anyway. Does that help any?

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

From bouncefilter Mon Nov 22 16:35:56 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id QAA68684
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 16:35:00 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id QAA28028;
Mon, 22 Nov 1999 16:28:43 -0500
Message-ID: <3839B581.BD1C0CA4@wgcr.org>
Date: Mon, 22 Nov 1999 16:28:33 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: postgres RPM build on Suse linux 6.2
References: <XFMail.991122161134.vev@michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Vince Vielhaber wrote:

--with-tclconfig and/or --with-tkconfig should fix this. I forget
whether those are in 6.5.* though.

I added --with-tkconfig somewhere around March 4, 1999. That's the date
on my patch file anyway. Does that help any?

Well, I told the guy to symlink /usr/X11/lib/tkConfig.sh to
/usr/lib/tkConfig.sh to assist in troubleshooting the build -- and
that's when we run up against the X stuff. He is confirming that he
indeed has the X11 development headers and libs installed.

The long term solution is to add distribution-specific configure lines
to the spec file, selected with RPM directives. We just have to figure
out the configure options and other shenanigans for each distribution,
then put the appropriate directives in place. Once we get his system
building the RPM's reliably, then we'll do the --with-tkconfig etc
directives in the spec file, with the selector directives inline. At
that point, whether you are on RedHat or SuSE, you just type 'rpm
--rebuild postgresql-6.5.3-x.src.rpm' and the entire build, install, and
packaging operations are executed in a fully automatic fashion,
producing installable binary RPM's. At least that's my goal ;-).

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

From bouncefilter Mon Nov 22 17:05:56 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA73049
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 17:04:57 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm219.noc.fukui.nsk.ne.jp [210.161.188.94])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id HAA02573; Tue, 23 Nov 1999 07:04:28 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] 7.0 status request
Date: Tue, 23 Nov 1999 07:04:27 +0900
Message-ID: <NABBINCKAKFCDDKMMJHGKEMBDLAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <1551.942994965@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
Sent: Friday, November 19, 1999 4:03 PM
To: Bruce Momjian
Cc: PostgreSQL-development
Subject: Re: [HACKERS] 7.0 status request

I think there are also a lot of unresolved questions about interlocking
and updating of the catalog caches and relcache. These might be
must-fix items. IIRC, Hiroshi is pretty concerned about that area...

Unfortunately I don't have a reasonable solution for interlocking yet.
First,row level locking for system tuples not only exclusive but
also shared will be needed. I couldn't find the way to implement
shared row level locking now.
Moreover I'm suspicious that this row level locking could be used
for parser/planner. Row level locking(at least in current implemen
tation) is held till end of transaction.

As for cache invalidation(rollback),I may be able to do something.
However new save point feature would need some change around
it. I don't know how Vadim would change it.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Nov 22 20:46:59 1999
Received: from thelab.hub.org (nat198.58.mpoweredpc.net [142.177.198.58])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA06369
for <pgsql-hackers@postgresql.org>;
Mon, 22 Nov 1999 20:46:58 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA52593;
Mon, 22 Nov 1999 21:45:28 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 22 Nov 1999 21:45:21 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: TODO updates
In-Reply-To: <199911221803.NAA06011@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9911222144290.14653-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

one of the things I remember seeing discussed, and wonder about current
status on:

removal of the whole pg_vlock requirement on vacuum?

last I recall, MVCC eliminated that requirement, and also made it easier
to do a vacuum on 'live tables'?

On Mon, 22 Nov 1999, Bruce Momjian wrote:

The following TODO items seem to be taken care of in current sources,
but aren't marked done in TODO:

Thanks. I have trouble figuring out which fixes I hear about go with
which items. I also forget they are on there.

PARSER

* INSERT INTO ... SELECT with AS columns matching result columns problem
* UNION with LIMIT fails
* CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
* CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
* mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
* SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes

Thanks. Done.

URGENT

* Eliminate limits on query length

(Not quite done, but close enough to put a dash on it...)

Marked.

TYPES

* Allow compression of large fields or a compressed field type

Jan just created a compressed text type, so this is partly done.
We speculated a little about adding a lower-level mechanism that would
compress whole tuples, so maybe this item should be replaced by one
mentioning that idea (it wouldn't belong in the TYPES section though).

Marked. Let someone ask for tuple compression.

MISC

* Allow subqueries in target list

Marked.

* Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup

Is this one done, or do we still have issues there? I think it's a lot
better than it used to be, anyway...

Marked.

SOURCE CODE

* Make configure --enable-debug add -g on compile line

Marked.

Thanks. Updated.

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

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

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

From bouncefilter Mon Nov 22 20:52: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 UAA07251
for <pgsql-hackers@postgresql.org>;
Mon, 22 Nov 1999 20:52:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id UAA26207;
Mon, 22 Nov 1999 20:51:22 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: TODO updates
In-reply-to: Your message of Mon, 22 Nov 1999 21:45:21 -0400 (AST)
<Pine.BSF.4.10.9911222144290.14653-100000@thelab.hub.org>
Date: Mon, 22 Nov 1999 20:51:21 -0500
Message-ID: <26205.943321881@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

one of the things I remember seeing discussed, and wonder about current
status on:
removal of the whole pg_vlock requirement on vacuum?

I have that on my to-do list; as far as I know it's a trivial code
change, but I just haven't gotten to it. Maybe I'll try it tonight.

regards, tom lane

From bouncefilter Mon Nov 22 21:54:59 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 VAA15525
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 21:53:59 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id JAA02723;
Tue, 23 Nov 1999 09:50:24 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <383A00F0.12A0D630@krs.ru>
Date: Tue, 23 Nov 1999 09:50:24 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] 7.0 status request
References: <NABBINCKAKFCDDKMMJHGKEMBDLAA.Inoue@tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hiroshi Inoue wrote:

As for cache invalidation(rollback),I may be able to do something.
However new save point feature would need some change around
it. I don't know how Vadim would change it.

I have no plans to implement it for 7.0...

Vadim

From bouncefilter Mon Nov 22 21:58: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 VAA16338
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 21:58:35 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id CAA28131;
Tue, 23 Nov 1999 02:51:12 GMT
Sender: lockhart@hub.org
Message-ID: <383A0120.708B68BF@alumni.caltech.edu>
Date: Tue, 23 Nov 1999 02:51: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: Lamar Owen <lamar.owen@wgcr.org>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Mandrake RPMs (was RPM build on Suse linux 6.2)
References: <199911221747.MAA04455@candle.pha.pa.us>
<38398D73.8D466F32@wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ok. I'm going to have to do some digging -- there are a multitude of
other X11-related configure shenanigans I'm going to have to take care
of for building the RPMs on SuSE. I eventually hope to have it where
people can rebuild the RPM set with a simple 'rpm --rebuild' instead of
what some are having to do now. On RedHat Intel, Sparc, or Alpha, the
--rebuild is enough -- but RedHat is not the only RPM-based distribution
(nor is linux the only OS that can have RPM installed....). Time to buy
CheapBytes' Mondo CD pack (five linux distributions on CD)....

I've sent off mail to the Mandrake folks regarding the Postgres RPMs;
will let you know what I find out. Current problems:

1) they don't have the latest release. I asked whether they had a
mechanism for releasing updates to packages over and above the limited
number I see on their site.

2) they seem to have omitted the .src.rpm from their distro, so I
can't see how they build their i586-specific packages.

btw, they show the same /usr/lib/pgsql permissions problem.

- Thomas

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

From bouncefilter Mon Nov 22 21:52:59 1999
Received: from thelab.hub.org (nat198.58.mpoweredpc.net [142.177.198.58])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA15381
for <pgsql-hackers@postgresql.org>;
Mon, 22 Nov 1999 21:52:25 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA57602;
Mon, 22 Nov 1999 22:51:43 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 22 Nov 1999 22:51:42 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: TODO updates
In-Reply-To: <26205.943321881@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.10.9911222250470.14653-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 22 Nov 1999, Tom Lane wrote:

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

one of the things I remember seeing discussed, and wonder about current
status on:
removal of the whole pg_vlock requirement on vacuum?

I have that on my to-do list; as far as I know it's a trivial code
change, but I just haven't gotten to it. Maybe I'll try it tonight.

is this something that could safely be back-patched into v6.5.x's tree?
have at least one project that could really use the ability to vacuum a
database without the tables being locked :)

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

From bouncefilter Mon Nov 22 22:17:59 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA19534
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 22:17:51 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id MAA02763; Tue, 23 Nov 1999 12:16:20 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Vadim Mikheev" <vadim@krs.ru>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, "Bruce Momjian" <pgman@candle.pha.pa.us>,
"PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] 7.0 status request
Date: Tue, 23 Nov 1999 12:20:57 +0900
Message-ID: <000501bf3561$c1e3e0e0$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: <383A00F0.12A0D630@krs.ru>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: root@sunpine.krs.ru [mailto:root@sunpine.krs.ru]On Behalf Of Vadim
Mikheev
Sent: Tuesday, November 23, 1999 11:50 AM
To: Hiroshi Inoue
Cc: Tom Lane; Bruce Momjian; PostgreSQL-development
Subject: Re: [HACKERS] 7.0 status request

Hiroshi Inoue wrote:

As for cache invalidation(rollback),I may be able to do something.
However new save point feature would need some change around
it. I don't know how Vadim would change it.

I have no plans to implement it for 7.0...

Doesn't ROLLBACK to a save point rollback catalog cache ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Nov 22 22:25:00 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 WAA20359
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 22:24:33 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id KAA02912;
Tue, 23 Nov 1999 10:20:59 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <383A081B.8AFCC4AE@krs.ru>
Date: Tue, 23 Nov 1999 10:20:59 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] 7.0 status request
References: <000501bf3561$c1e3e0e0$2801007e@cadzone.tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hiroshi Inoue wrote:

As for cache invalidation(rollback),I may be able to do something.
However new save point feature would need some change around
it. I don't know how Vadim would change it.

I have no plans to implement it for 7.0...

Doesn't ROLLBACK to a save point rollback catalog cache ?

There will be no savepoints in 7.0...
But I'm going to rollback all changes made by xaction
on abort...

Vadim

From bouncefilter Mon Nov 22 23:03:02 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA26027
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 23:02:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA09144;
Mon, 22 Nov 1999 22:38:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911230338.WAA09144@candle.pha.pa.us>
Subject: Re: [HACKERS] 7.0 status request
In-Reply-To: <000501bf3561$c1e3e0e0$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Nov 23, 1999 12:20:57 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Mon, 22 Nov 1999 22:38:06 -0500 (EST)
CC: Vadim Mikheev <vadim@krs.ru>, Tom Lane <tgl@sss.pgh.pa.us>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hiroshi Inoue wrote:

As for cache invalidation(rollback),I may be able to do something.
However new save point feature would need some change around
it. I don't know how Vadim would change it.

I have no plans to implement it for 7.0...

Doesn't ROLLBACK to a save point rollback catalog cache ?

I thought we flush cache on abort, no?

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

From bouncefilter Mon Nov 22 23:34:01 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA31733
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 23:33:23 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org ([207.144.78.40])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id XAA28513;
Mon, 22 Nov 1999 23:32:49 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Subject: Re: Mandrake RPMs (was RPM build on Suse linux 6.2)
Date: Mon, 22 Nov 1999 22:58:02 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
References: <199911221747.MAA04455@candle.pha.pa.us>
<38398D73.8D466F32@wgcr.org> <383A0120.708B68BF@alumni.caltech.edu>
In-Reply-To: <383A0120.708B68BF@alumni.caltech.edu>
MIME-Version: 1.0
Message-Id: <99112223350202.00597@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Mon, 22 Nov 1999, Thomas Lockhart wrote:

--rebuild is enough -- but RedHat is not the only RPM-based distribution
(nor is linux the only OS that can have RPM installed....). Time to buy
CheapBytes' Mondo CD pack (five linux distributions on CD)....

I've sent off mail to the Mandrake folks regarding the Postgres RPMs;
will let you know what I find out. Current problems:

1) they don't have the latest release. I asked whether they had a
mechanism for releasing updates to packages over and above the limited
number I see on their site.

The last Mandrake release is for the Cooker development setup (go to
rpmfind.net, Mandrake Cooker, pull up a RPM list by name, and go to the P's.).
They last put in 6.5.2-1 in Cooker. And Cooker has the src.rpm.

btw, they show the same /usr/lib/pgsql permissions problem.

Yeah, that one is going to bite us one day. There was never a documented need
to change it before. It is changed in my local copy of the spec file already,
so it will go into the next build (as the gruesome HOWTO gets canned at the
same time.... I didn't want to look _too_ eager to find an excuse to release
another RPM set so soon after our HOWTO discussion and resolution....).

Do you have a preference as to doing a quick bugfix RPM release versus waiting
a little to get other bugs squashed at the same time?

Can you forward Mandrake's reply to me??

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

From bouncefilter Mon Nov 22 23:14:01 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA28503
for <pgsql-hackers@postgreSQL.org>;
Mon, 22 Nov 1999 23:13:54 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id NAA02785; Tue, 23 Nov 1999 13:12:53 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Vadim Mikheev" <vadim@krs.ru>, "Tom Lane" <tgl@sss.pgh.pa.us>,
"PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] 7.0 status request
Date: Tue, 23 Nov 1999 13:17:29 +0900
Message-ID: <000601bf3569$a82b2020$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: <199911230338.WAA09144@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
Sent: Tuesday, November 23, 1999 12:38 PM
To: Hiroshi Inoue
Cc: Vadim Mikheev; Tom Lane; PostgreSQL-development
Subject: Re: [HACKERS] 7.0 status request

Hiroshi Inoue wrote:

As for cache invalidation(rollback),I may be able to do something.
However new save point feature would need some change around
it. I don't know how Vadim would change it.

I have no plans to implement it for 7.0...

Doesn't ROLLBACK to a save point rollback catalog cache ?

I thought we flush cache on abort, no?

Sorry,I don't remember well now.
But at least catalog cache is not rollbacked for the transaction
itself in case of abort.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Nov 22 23:38:01 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA32283
for <pgsql-hackers@postgresql.org>;
Mon, 22 Nov 1999 23:37:03 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA04236;
Mon, 22 Nov 1999 23:35:22 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] System cache index cleanup
In-reply-to: Your message of Mon, 22 Nov 1999 12:59:25 -0500 (EST)
<199911221759.MAA05297@candle.pha.pa.us>
Date: Mon, 22 Nov 1999 23:35:22 -0500
Message-ID: <4234.943331722@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

I have made most system indexes unique.

Bruce, I think you need to revert the following changes to pg_opclass.h:

*** src/include/catalog/pg_opclass.h	1999/09/29 21:13:30	1.20
--- src/include/catalog/pg_opclass.h	1999/11/22 17:36:15
***************
*** 68,76 ****
  DESCR("");
  DATA(insert OID =  423 (	float8_ops		701   ));
  DESCR("");
! DATA(insert OID =  424 (	int24_ops		  0   ));
  DESCR("");
! DATA(insert OID =  425 (	int42_ops		  0   ));
  DESCR("");
  DATA(insert OID =  426 (	int4_ops		 23   ));
  DESCR("");
--- 68,78 ----
  DESCR("");
  DATA(insert OID =  423 (	float8_ops		701   ));
  DESCR("");
! /* Technically, deftype is wrong, but it must be unique for index, bjm */
! DATA(insert OID =  424 (	int24_ops		424   ));
  DESCR("");
! /* Technically, deftype is wrong, but it must be unique for index, bjm */
! DATA(insert OID =  425 (	int42_ops		425   ));
  DESCR("");
  DATA(insert OID =  426 (	int4_ops		 23   ));
  DESCR("");
***************
*** 85,91 ****
  DESCR("");
  DATA(insert OID =  432 (	abstime_ops		702   ));
  DESCR("");
! DATA(insert OID =  433 (	bigbox_ops		603   ));
  DESCR("");
  DATA(insert OID =  434 (	poly_ops		604   ));
  DESCR("");
--- 87,94 ----
  DESCR("");
  DATA(insert OID =  432 (	abstime_ops		702   ));
  DESCR("");
! /* Technically, deftype is wrong, but it must be unique for index, bjm */
! DATA(insert OID =  433 (	bigbox_ops		433   ));
  DESCR("");
  DATA(insert OID =  434 (	poly_ops		604   ));
  DESCR("");

and make the corresponding index non-unique.

(a) It is not supposed to be a unique column --- we'd not need the
concept of index opclasses at all if there were only one possible
operator set for any given column type!

(b) The above changes are making the oidjoins and opr_sanity regress
tests fail, as indeed they should...

regards, tom lane

From bouncefilter Mon Nov 22 23:52:02 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA34418
for <pgsql-hackers@postgresql.org>;
Mon, 22 Nov 1999 23:51:02 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA14776;
Mon, 22 Nov 1999 23:48:16 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911230448.XAA14776@candle.pha.pa.us>
Subject: Re: [HACKERS] System cache index cleanup
In-Reply-To: <4234.943331722@sss.pgh.pa.us> from Tom Lane at "Nov 22,
1999 11:35:22 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 22 Nov 1999 23:48:16 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgresql.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

I have made most system indexes unique.

Bruce, I think you need to revert the following changes to pg_opclass.h:

*** src/include/catalog/pg_opclass.h	1999/09/29 21:13:30	1.20
--- src/include/catalog/pg_opclass.h	1999/11/22 17:36:15
***************
*** 68,76 ****
DESCR("");
DATA(insert OID =  423 (	float8_ops		701   ));
DESCR("");
! DATA(insert OID =  424 (	int24_ops		  0   ));
DESCR("");
! DATA(insert OID =  425 (	int42_ops		  0   ));
DESCR("");
DATA(insert OID =  426 (	int4_ops		 23   ));
DESCR("");
--- 68,78 ----
DESCR("");
DATA(insert OID =  423 (	float8_ops		701   ));
DESCR("");
! /* Technically, deftype is wrong, but it must be unique for index, bjm */
! DATA(insert OID =  424 (	int24_ops		424   ));
DESCR("");
! /* Technically, deftype is wrong, but it must be unique for index, bjm */
! DATA(insert OID =  425 (	int42_ops		425   ));
DESCR("");
DATA(insert OID =  426 (	int4_ops		 23   ));
DESCR("");
***************
*** 85,91 ****
DESCR("");
DATA(insert OID =  432 (	abstime_ops		702   ));
DESCR("");
! DATA(insert OID =  433 (	bigbox_ops		603   ));
DESCR("");
DATA(insert OID =  434 (	poly_ops		604   ));
DESCR("");
--- 87,94 ----
DESCR("");
DATA(insert OID =  432 (	abstime_ops		702   ));
DESCR("");
! /* Technically, deftype is wrong, but it must be unique for index, bjm */
! DATA(insert OID =  433 (	bigbox_ops		433   ));
DESCR("");
DATA(insert OID =  434 (	poly_ops		604   ));
DESCR("");

and make the corresponding index non-unique.

(a) It is not supposed to be a unique column --- we'd not need the
concept of index opclasses at all if there were only one possible
operator set for any given column type!

(b) The above changes are making the oidjoins and opr_sanity regress
tests fail, as indeed they should...

Patch reverse applied, and index no longer unique. I saw these errors
too but was unsure of the cause and whether it was significant.

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

From bouncefilter Tue Nov 23 00:02:13 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA36804
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 00:00:02 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA04257;
Mon, 22 Nov 1999 23:58:09 -0500 (EST)
To: The Hermit Hacker <scrappy@hub.org>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: TODO updates
In-reply-to: Your message of Mon, 22 Nov 1999 22:51:42 -0400 (AST)
<Pine.BSF.4.10.9911222250470.14653-100000@thelab.hub.org>
Date: Mon, 22 Nov 1999 23:58:08 -0500
Message-ID: <4255.943333088@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

removal of the whole pg_vlock requirement on vacuum?

I have that on my to-do list; as far as I know it's a trivial code
change, but I just haven't gotten to it. Maybe I'll try it tonight.

is this something that could safely be back-patched into v6.5.x's tree?

Well, mumble. We could probably back-patch the ability to run more than
one vacuum at a time, since that'd be local to vacuum.c. But I think
that'd encourage people to run vacuum in parallel with *other* database
activities, something we know is not very safe in 6.5! That whole
set of changes I made to enforce more careful locking was mainly
motivated by Oleg's examples of crashes when system table changes were
made in parallel with vacuuming of the system tables.

In short, I think it'd be a risky thing to do. I'm not even 100%
confident that it will work reliably in current sources; I'll check
it out before I commit it, but I won't be really comfortable until
we've had a beta-test cycle on it...

regards, tom lane

From bouncefilter Tue Nov 23 01:42:02 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA50611
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 01:41:42 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA05070
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 01:41:06 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Concurrent VACUUM: first results
Date: Tue, 23 Nov 1999 01:41:05 -0500
Message-ID: <5068.943339265@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Well, I diked out the code in vacuum.c that creates/deletes the pg_vlock
lockfile, and tried it out. Turns out it's not quite such a no-brainer
as I'd hoped. Several problems emerged:

1. You can run concurrent "VACUUM" this way, but concurrent "VACUUM
ANALYZE" blows up. The problem seems to be that "VACUUM ANALYZE"'s
first move is to delete all available rows in pg_statistic. That
generates a conflict against other vacuums that might be inserting new
rows in pg_statistic. The newly started VACUUM will almost always hang
up on a not-yet-committed pg_statistic row, waiting to see whether that
row commits so that it can delete it. Even more interesting, the older
VACUUM generally hangs up shortly after that; I'm not perfectly clear on
what *it's* waiting on, but it's obviously a mutual deadlock situation.
The two VACUUMs don't fail with a nice "deadlock detected" message,
either ... it's more like a 60-second spinlock timeout, followed by
abort() coredumps in both backends, followed by the postmaster killing
every other backend in sight. That's clearly not acceptable behavior
for production databases.

I find this really disturbing whether we allow concurrent VACUUMs or
not, because now I'm afraid that other sorts of system-table updates
can show the same ungraceful response to deadlock situations. I have
a vague recollection that Vadim said something about interlocks between
multiple writers only being done properly for user tables not system
tables ... if that's what this is, I think it's a must-fix problem.

2. I was able to avoid the deadlock by removing the code that tries to
delete every pg_statistic tuple in sight. The remaining code deletes
(and then recreates) pg_statistics tuples for each table it processes,
while it's processing the table and holding an exclusive lock on the
table. So, there's no danger of cross-VACUUM deadlocks. The trouble is
that pg_statistics tuples for deleted tables won't ever go away, since
VACUUM will never consider them. I suppose this could be fixed by
modifying DROP TABLE to delete pg_statistics tuples applying to the
target table.

3. I tried running VACUUMs in parallel with the regress tests, and saw
a lot of messages like
NOTICE: Rel tenk1: TID 1/31: InsertTransactionInProgress 29737 - can't shrink relation
Looking at the code, this is normal behavior for VACUUM when it sees
not-yet-committed tuples, and has nothing to do with whether there's
another VACUUM going on elsewhere. BUT: why the heck are we getting
these at all, especially on user tables? VACUUM's grabbed an exclusive
lock on the target table; shouldn't that mean that all write
transactions on the target have committed? This looks like it could
be a symptom of a locking bug.

Do we want to press ahead with fixing these problems, or should I just
discard my changes uncommitted? Two of the three points look like
things we need to worry about whether VACUUM is concurrent or not,
but maybe I'm misinterpreting what I see. Comments?

regards, tom lane

From bouncefilter Tue Nov 23 02:12:05 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA54337
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 02:11:14 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id CAA05126
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 02:10:39 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: VACUUM as a denial-of-service attack
Date: Tue, 23 Nov 1999 02:10:39 -0500
Message-ID: <5124.943341039@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Whilst playing around with concurrent VACUUMs (see previous message),
I looked at some other issues that were on my TODO list. I think
these deserve a separate thread:

1. VACUUM does internal start/commit-transaction calls around the
processing of each table it handles. That's good, because it ensures
that the results of vacuuming each table are committed down to disk
before we move on to vacuuming the next one (and take the ever-present
chance of failure). But if VACUUM is invoked inside a BEGIN/END
transaction block, those start/commit-transaction calls don't actually
commit anything; they reduce to plain statement boundaries within
the transaction. This is Bad, Very Bad, on two grounds:
(a) abort while vacuuming a later table imperils the results for all
prior tables, since they won't get committed;
(b) by the time we approach the end of vacuuming a whole database,
we will hold exclusive locks on just about everything, which will
not be good for the progress of any actual work being done by
other backends. Not to mention the very strong possibility of
hitting a deadlock against locks held by other backends.

I had previously suggested banning VACUUM inside a transaction block
to forestall these problems. I now see that the problems really only
apply to the case of VACUUMing a whole database --- the variant of
VACUUM that processes only a single table could be allowed inside
a BEGIN/END block, and it wouldn't create any problems worse than
any other command that grabs exclusive access on a table. (OK,
you could BEGIN and then VACUUM a lot of tables one by one, but
then you deserve any problems you get...)

So: should VACUUM refuse to run inside BEGIN at all, or should it
refuse only the whole-database variant? The former would be more
consistent and easier to explain, but the latter might be more useful.

2. It is a serious security breach that any random user can VACUUM
any table. Particularly in the current code, where VACUUM can be
done inside a transaction, because that means the user can sit on
the locks acquired by VACUUM. I can't do "lock table pg_shadow"
as an unprivileged user --- but I can do "begin; vacuum pg_shadow;
<twiddle thumbs>". Guess what happens when subsequent users try
to connect.

Even if we disallow all forms of VACUUM inside transactions, one
could still mount a moderately effective denial-of-service attack
by issuing a continuous stream of "vacuum pg_shadow" commands,
or perhaps repeated vacuums of some large-and-mission-critical
user table.

I think a reasonable answer to this is to restrict VACUUM on any
table to be allowed only to the table owner and Postgres superuser.
Does anyone have an objection or better idea?

regards, tom lane

From bouncefilter Tue Nov 23 03:59:04 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 DAA69935
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 03:58:16 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id JAA31690
for <pgsql-hackers@postgreSQL.org>; Tue, 23 Nov 1999 09:58:14 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQVZ5>; Tue, 23 Nov 1999 09:58:14 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC183@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: AW: [HACKERS] Getting OID in psql of recent insert
Date: Tue, 23 Nov 1999 09:58:08 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Yes, I use 'em the same way. I think an OID is kind of

like a pointer

in a C program: good for fast, unique access to an object

within the

context of the execution of a particular application (and maybe not
even that long). You don't write pointers into files to

be used again

by other programs, though, and in the same way an OID isn't a good
candidate for a long-lasting reference from one table to another.

I thought this special case is where the new xid access

method would come

in.

Good point, but (AFAIK) you could only use it for tables that you were
sure no other client was updating in parallel. Otherwise you might be
updating a just-obsoleted tuple. Or is there a solution for that?

Ok, the fact, that the row changed is known, because we can check the
snapshot. We also know, that the new row must be near the physical end
of the table, so maybe we could do a backward scan ?
Maybe we could also simply bail out, like Oracle with a "snapshot too old"
error message ?
(I know that this is not the same situation as the stated Oracle error)

Is someone still working on the xid access ?

I think we have the ability to refer to CTID in WHERE now,

Do we use the sql syntax 'where rowid = :xxx' for it,
or do we say 'where ctid = :xxx'.
I would like the rowid naming, because Informix, Oracle (and DB/2 ?) use it.

but not yet an access method that actually makes it fast...

Well that is of course only half the fun :-(
Could it be done like an index access,
where the first part of the work is skipped, or tunneled through ?

Andreas

From bouncefilter Tue Nov 23 04:20:06 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 EAA73068
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 04:19:59 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id SAA02897; Tue, 23 Nov 1999 18:18:27 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Concurrent VACUUM: first results
Date: Tue, 23 Nov 1999 18:23:03 +0900
Message-ID: <000a01bf3594$58002660$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <5068.943339265@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
Sent: Tuesday, November 23, 1999 3:41 PM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] Concurrent VACUUM: first results

Well, I diked out the code in vacuum.c that creates/deletes the pg_vlock
lockfile, and tried it out. Turns out it's not quite such a no-brainer
as I'd hoped. Several problems emerged:

3. I tried running VACUUMs in parallel with the regress tests, and saw
a lot of messages like
NOTICE: Rel tenk1: TID 1/31: InsertTransactionInProgress 29737 -
can't shrink relation
Looking at the code, this is normal behavior for VACUUM when it sees
not-yet-committed tuples, and has nothing to do with whether there's
another VACUUM going on elsewhere. BUT: why the heck are we getting
these at all, especially on user tables? VACUUM's grabbed an exclusive
lock on the target table; shouldn't that mean that all write
transactions on the target have committed? This looks like it could
be a symptom of a locking bug.

Doesn't DoCopy() in copy.c unlock the target relation too early
by heap_close() ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Nov 23 04:18:04 1999
Received: from mail.psn.ne.jp (mail.psn.ne.jp [210.167.249.5])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA72874
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 04:17:50 -0500 (EST)
(envelope-from sakaida@psn.co.jp)
Received: from g6o9i2 (ppp060.psn.ne.jp [210.167.249.60])
by mail.psn.ne.jp (8.9.1/3.7W) with SMTP id SAA00406
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 18:17:47 +0900 (JST)
Date: Tue, 23 Nov 1999 18:24:52 +0900
From: SAKAIDA Masaaki <sakaida@psn.co.jp>
To: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Getting OID in psql of recent insert
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC181@sdexcsrv1.f000.d0188.sd.spardat.at>
References:
<219F68D65015D011A8E000006F8590C603FDC181@sdexcsrv1.f000.d0188.sd.spardat.at>
Message-Id: <383A5D641E0.D5F5SAKAIDA@smtp.psn.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver 1.25.07

Hi,

testdb=> \set singlestep on
testdb=> \set sql_interpol '#'
testdb=> \set foo 'pg_class'
testdb=> select * from #foo#;

In order to solve these problems, I have adopted a approach
which is different from psql. It is 'pgbash'. The pgbash is
the system which offers the direct SQL/embedded SQL interface
for PostgreSQL by being included in the BASH(Version 2) shell.
Please refer to the next URL.
http://www.psn.co.jp/PostgreSQL/pgbash/index-e.html

ex.)
pgbash> exec_sql "insert into test values(111,'aaa','bbb')"
pgabsh> rOID=$SQLOID <---- OID of recent insert
pgbash> exec_sql "begin"
pgbash> exec_sql "declare cur cursor fr select * from test

where oid >= $rOID2 and oid <= $rOID"

pgbash> exec_sql "fetch in cur into :NUM1, :NAME1"
pgbash> exec_sql "fetch in cur into :NUM2, :NAME2"
pgbash> NUM=$(( $NUM1+$NUM2 ))
pgbash> echo $NUM, $NAME1, $NAME2
pgbash> exec_sql "end"

Now, pgbash version is 1.2.3 and this version needs 'exec_sql'
to execute SQL. However, I have changed a parser of BASH-2.03,
and pgbash becomes BASH itself in the next version. It does not
need to describe 'exec_sql' in order to execute SQL.

ex.)
pgbash> insert into test values(111,'aaa','bbb');
pgbash> rOID = $SQLOID
pgbash> select * from test where oid=$rOID; &> /tmp/work.dat

'SQL;' becomes one command of BASH shell. Therefore, it is
possible to use ridirection/pipe with SQL. By this, pgbash has
the operability equal to psql and it will also have many functions
which are higher than psql.

I think this approach useful. Comments?

--
Regards,
SAKAIDA Masaaki <sakaida@psn.co.jp>
Personal Software, Inc. Osaka, Japan

From bouncefilter Tue Nov 23 04:41:05 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 EAA75923
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 04:40:27 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id SAA02902; Tue, 23 Nov 1999 18:40:14 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Zeugswetter Andreas SEV" <ZeugswetterA@wien.spardat.at>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: AW: [HACKERS] Getting OID in psql of recent insert
Date: Tue, 23 Nov 1999 18:44:51 +0900
Message-ID: <000b01bf3597$6340fb00$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:
<219F68D65015D011A8E000006F8590C603FDC183@sdexcsrv1.f000.d0188.sd.spardat.at>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Zeugswetter
Andreas SEV
Sent: Tuesday, November 23, 1999 5:58 PM
To: 'pgsql-hackers@postgreSQL.org'
Subject: AW: AW: [HACKERS] Getting OID in psql of recent insert

Is someone still working on the xid access ?

I think we have the ability to refer to CTID in WHERE now,

Do we use the sql syntax 'where rowid = :xxx' for it,
or do we say 'where ctid = :xxx'.
I would like the rowid naming, because Informix, Oracle (and DB/2
?) use it.

You could say 'where ctid= ...' in current tree.
It has been rejected due to the lack of equal operator for type TID.
The syntax itself has been allowed by parser.

but not yet an access method that actually makes it fast...

Well that is of course only half the fun :-(
Could it be done like an index access,
where the first part of the work is skipped, or tunneled through ?

I would commit the implementation of direct scan by tuple id soon.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Tue Nov 23 05:32:05 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 FAA83672
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 05:31:15 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id LAA223244;
Tue, 23 Nov 1999 11:31:12 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQWTD>; Tue, 23 Nov 1999 11:31:12 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC184@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
Subject: SQL statements: begin and end
Date: Tue, 23 Nov 1999 11:31:04 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

I see everybody using the following PostgreSQL statements:

"begin" instead of "begin work"
"end" instead of "commit work"

This is really bad, because it is not standard, and can easily be taken for
a statement block, which it is definitely not ! It is a transaction block.

I vote for issuing a NOTICE for these in V7 and remove them in V8,
at least the single "end"

Bruce, please don't use "begin" and "end" in your book.

Andreas

From bouncefilter Tue Nov 23 05:35:06 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id FAA83963
for <docs@postgreSQL.org>; Tue, 23 Nov 1999 05:34:08 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 22839 invoked by uid 1001); 23 Nov 1999 10:34:09 -0000
Date: Tue, 23 Nov 1999 05:34:08 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: docs@postgreSQL.org
Subject: RE: file name error (fwd)
Message-ID: <Pine.BSF.4.05.9911230533210.22824-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Forwarded from webmaster.

---------- Forwarded message ----------
Date: Mon, 22 Nov 1999 22:17:14 -0600
From: Brian D. Woodruff <wood@TuneStreet.com>
Subject: RE: file name error

ooh - sorry to be so vague! It's in a frame set, linked from Administration
in the Documentation section. The URL is:

http://postgresql.org/docs/admin/install761.htm

steps in the list which have problems are:

4, 6, 10, and 26

due to the "v" in the filename which is not in the filename on the FTP server.

other parts of the install process have incorrect paths, for instance, in
step 11, there is a change directory issued to:

/usr/src/pgsql/src/

which should really go to:

/usr/src/pgsql/postgresql-6.5.3/src/

This occurs in several places in the doc.

Apparently the path above is where the tar file puts things.

Other than that, the installation went well! This installation is on my
third server. Having fun with it :-)

You can see it in action on the order page of www.IncWay.com :-)

Again, I hope I'm being helpful! Thanks!

BDW

At 07:09 PM 11/22/99 -0500, you wrote:

On 21-Nov-99 Brian D. Woodruff wrote:

please pass this on to the appropriate parties ...

the file name referenced in the installation guide is

postgresql-v6.5.3.tar.gz

whereast the real file name has no "v" before the six on the FTP site.

I suppose a soft link would be a good "quick fix"!

no big deal, but it means c/p installation doesn't work!

Which installation guide?

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

From bouncefilter Tue Nov 23 05:38:05 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 FAA84543
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 05:37:48 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id LAA223338;
Tue, 23 Nov 1999 11:37:36 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQWVH>; Tue, 23 Nov 1999 11:37:37 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC185@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'Hiroshi Inoue'" <Inoue@tpf.co.jp>
Cc: pgsql-hackers@postgreSQL.org
Subject: AW: AW: [HACKERS] Getting OID in psql of recent insert
Date: Tue, 23 Nov 1999 11:37:25 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

but not yet an access method that actually makes it fast...

Well that is of course only half the fun :-(
Could it be done like an index access,
where the first part of the work is skipped, or tunneled through ?

I would commit the implementation of direct scan by tuple id soon.

Sounds like it is going to be a fantastic christmas :-)

Thank you
Andreas

From bouncefilter Tue Nov 23 07:01:10 1999
Received: from Radha.DoCS.UU.SE (root@Radha.DoCS.UU.SE [130.238.9.99])
by hub.org (8.9.3/8.9.3) with SMTP id HAA95019
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 07:00:52 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Panda.DoCS.UU.SE (e99re41@Panda.DoCS.UU.SE [130.238.9.117]) by
Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id MAA03297;
Tue, 23 Nov 1999 12:52:18 +0100
Received: from localhost (e99re41@localhost) by Panda.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA14174;
Tue, 23 Nov 1999 12:52:17 +0100
X-Authentication-Warning: Panda.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Tue, 23 Nov 1999 12:52:16 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
cc: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] SQL statements: begin and end
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC184@sdexcsrv1.f000.d0188.sd.spardat.at>
Message-ID: <Pine.GSO.4.02A.9911231249210.14139-100000@Panda.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Whatever happened to
BEGIN TRANSACTION;
...
COMMIT;

I never liked END to begin with, since it doesn't really imply that you
are committing anything. Or what is the non-committing counterpart of END?

But I think we should go strictly with the SQL standard, even if that
contradicts what I just said. (?)

-Peter

On Tue, 23 Nov 1999, Zeugswetter Andreas SEV wrote:

I see everybody using the following PostgreSQL statements:

"begin" instead of "begin work"
"end" instead of "commit work"

This is really bad, because it is not standard, and can easily be taken for
a statement block, which it is definitely not ! It is a transaction block.

I vote for issuing a NOTICE for these in V7 and remove them in V8,
at least the single "end"

Bruce, please don't use "begin" and "end" in your book.

Andreas

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

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

From bouncefilter Tue Nov 23 09:20:07 1999
Received: from localhost (IDENT:root@hectic-2.jpl.nasa.gov [128.149.68.204])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA11394;
Tue, 23 Nov 1999 09:19:40 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA29389;
Tue, 23 Nov 1999 14:20:37 GMT
Sender: lockhart@hub.org
Message-ID: <383AA2B5.B8E8BB81@alumni.caltech.edu>
Date: Tue, 23 Nov 1999 14:20:37 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Meskes <meskes@postgreSQL.org>
CC: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Float/Numeric?
References: <19991122220616.A1895@fam-meskes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Shouldn't there be an implicit cast between numeric and float?

Yes there should. I'll add it to my list for v7.0 unless someone beats
me to it...

- Thomas

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

From bouncefilter Tue Nov 23 09:28:10 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 JAA12795;
Tue, 23 Nov 1999 09:28:05 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id OAA29396;
Tue, 23 Nov 1999 14:28:51 GMT
Sender: lockhart@hub.org
Message-ID: <383AA4A3.5B4510B9@alumni.caltech.edu>
Date: Tue, 23 Nov 1999 14:28:51 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Vince Vielhaber <vev@michvhf.com>
CC: docs@postgreSQL.org, Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [DOCS] RE: file name error (fwd)
References: <Pine.BSF.4.05.9911230533210.22824-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

http://postgresql.org/docs/admin/install761.htm
steps in the list which have problems are:
4, 6, 10, and 26
due to the "v" in the filename which is not in the filename on the FTP server.
other parts of the install process have incorrect paths

Was someone going to rewrite the installation procedure? I was looking
at it myself and agree with the thread from a month or two ago that it
is *much* too complicated and verbose. Several steps should be moved
to subsequent sections as reference or backup material (e.g. flex,
regression tests), and the whole thing could be substantially
condensed.

- Thomas

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

From bouncefilter Tue Nov 23 09:58:08 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id JAA17307
for <docs@postgreSQL.org>; Tue, 23 Nov 1999 09:58:02 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 23284 invoked by uid 1001); 23 Nov 1999 14:58:04 -0000
Date: Tue, 23 Nov 1999 09:58:04 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: docs@postgreSQL.org, Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [DOCS] RE: file name error (fwd)
In-Reply-To: <383AA4A3.5B4510B9@alumni.caltech.edu>
Message-ID: <Pine.BSF.4.05.9911230953560.23191-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 23 Nov 1999, Thomas Lockhart wrote:

http://postgresql.org/docs/admin/install761.htm
steps in the list which have problems are:
4, 6, 10, and 26
due to the "v" in the filename which is not in the filename on the FTP server.
other parts of the install process have incorrect paths

Was someone going to rewrite the installation procedure? I was looking
at it myself and agree with the thread from a month or two ago that it
is *much* too complicated and verbose. Several steps should be moved
to subsequent sections as reference or backup material (e.g. flex,
regression tests), and the whole thing could be substantially
condensed.

I was working on something that takes it down to about 5 steps before
the initdb phase of the installation - redirecting gmake's output was
optional. I'll see if it's still around.

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

From bouncefilter Tue Nov 23 10:01:10 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA17872
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 10:00:58 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id JAA06089;
Tue, 23 Nov 1999 09:59:54 -0500 (EST)
To: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
cc: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] SQL statements: begin and end
In-reply-to: Your message of Tue, 23 Nov 1999 11:31:04 +0100
<219F68D65015D011A8E000006F8590C603FDC184@sdexcsrv1.f000.d0188.sd.spardat.at>
Date: Tue, 23 Nov 1999 09:59:54 -0500
Message-ID: <6087.943369194@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at> writes:

I see everybody using the following PostgreSQL statements:
"begin" instead of "begin work"
"end" instead of "commit work"
This is really bad, because it is not standard,

I went looking in the SQL spec to confirm this, and was rather
startled to discover that BEGIN is not SQL at all! The SQL spec
seems to envision the always-in-a-transaction-block model of operation.
They have
<commit statement> ::=
COMMIT [ WORK ]
which is defined to commit the current transaction; but a new xact is
implicitly started by the next SQL operation (cf. sec. 4.28 in SQL92).

If we wanted to be completely standards-conformant, I think we'd have to
abandon the begin/end model entirely. I wouldn't support that ---
auto commit of standalone statements is too convenient.

Bottom line: pointing at the spec is a very weak argument for telling
people how to spell their begin/end statements.

I vote for issuing a NOTICE for these in V7 and remove them in V8,
at least the single "end"

My feeling is that application authors have already decided whether
they prefer "BEGIN" or "BEGIN TRANSACTION" or "BEGIN WORK", and trying
to enforce a single standard now is just going to irritate people and
break existing applications. I vote for leaving well enough alone.

Bruce, please don't use "begin" and "end" in your book.

Sure, it makes sense for the book to consistently use "BEGIN WORK"
and "COMMIT WORK", which are probably the least likely to confuse
novices. But I think actually removing the other variants would be
just an exercise in causing trouble.

regards, tom lane

From bouncefilter Tue Nov 23 10:17:08 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 KAA20593
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 10:16:13 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA29509;
Tue, 23 Nov 1999 15:16:58 GMT
Sender: lockhart@hub.org
Message-ID: <383AAFEA.29688B4F@alumni.caltech.edu>
Date: Tue, 23 Nov 1999 15:16:58 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] SQL statements: begin and end
References: <6087.943369194@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I went looking in the SQL spec to confirm this, and was rather
startled to discover that BEGIN is not SQL at all!

Right- me too! I glanced through the SQL98 docs I have (mostly from
'94) and there is no addition afaict. BEGIN/END *are* defined in SQL,
but only in the context of embedded SQL.

Bruce, please don't use "begin" and "end" in your book.

Sure, it makes sense for the book to consistently use "BEGIN WORK"
and "COMMIT WORK", which are probably the least likely to confuse
novices. But I think actually removing the other variants would be
just an exercise in causing trouble.

WORK is an optional noise word in SQL92. BEGIN WORK is not defined at
all, but I agree with Tom that the extension is essential.

I'm pretty sure that Andrea's biggest objection was to the acceptance
and use of END, which has no connection in official SQL to transaction
completion but only to block delimiting for cursor loops. It is almost
certainly a holdover from PostQuel.

Any thoughts on whether AZ's suggestion for dropping END in this
context should be done for 7.0? We certainly could make an effort to
at least purge it from our examples in the docs...

- Thomas

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

From bouncefilter Tue Nov 23 10:26:08 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 KAA22235
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 10:25:45 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id PAA29537;
Tue, 23 Nov 1999 15:26:30 GMT
Sender: lockhart@hub.org
Message-ID: <383AB226.B0FBCB67@alumni.caltech.edu>
Date: Tue, 23 Nov 1999 15:26: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: Lamar Owen <lamar.owen@wgcr.org>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: Mandrake RPMs (was RPM build on Suse linux 6.2)
References: <199911221747.MAA04455@candle.pha.pa.us>
<38398D73.8D466F32@wgcr.org> <383A0120.708B68BF@alumni.caltech.edu>
<99112223350202.00597@lorc.wgcr.org>
Content-Type: multipart/mixed; boundary="------------9701C623EF79D8ED423DA2DB"

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

--rebuild is enough -- but RedHat is not the only RPM-based distribution
(nor is linux the only OS that can have RPM installed....). Time to buy
CheapBytes' Mondo CD pack (five linux distributions on CD)....

I've sent off mail to the Mandrake folks regarding the Postgres RPMs;
will let you know what I find out. Current problems:
1) they don't have the latest release. I asked whether they had a
mechanism for releasing updates to packages over and above the limited
number I see on their site.

The last Mandrake release is for the Cooker development setup (go to
rpmfind.net, Mandrake Cooker, pull up a RPM list by name, and go to the P's.).
They last put in 6.5.2-1 in Cooker. And Cooker has the src.rpm.

I'm just using yours for now. Interesting: on my new laptop it builds
*i686* rpms, since the Mandrake /usr/lib/rpm/rpmrc is very aggressive
about matching the build machine. I have created a /root/.rpmrc to
override this, but I'm planning on posting some optimized RPMs at
postgresql.org.

We might also want to consider building some non-locale-enabled RPMs
so folks can get the speed boost if they aren't using non-ascii
English.

I've changed a couple of lines in the spec file; diffs included below.

Can you forward Mandrake's reply to me??

Sure. Haven't heard from them yet...

- Thomas

--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
--------------9701C623EF79D8ED423DA2DB
Content-Type: text/plain; charset=us-ascii;
name="postgresql-6.5.3-1.spec.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="postgresql-6.5.3-1.spec.patch"

*** postgresql-6.5.3-1.spec	Fri Nov  5 20:33:29 1999
--- postgresql-6.5.3-2mdk.spec	Tue Nov 23 13:57:45 1999
***************
*** 1,7 ****
  Summary: The PostgreSQL server programs.
  Name: postgresql
  Version: 6.5.3
! Release: 1
  Copyright: BSD
  Group: Applications/Databases
  Source0: ftp://ftp.postgresql.org/pub/postgresql-%{version}.tar.gz
--- 1,7 ----
  Summary: The PostgreSQL server programs.
  Name: postgresql
  Version: 6.5.3
! Release: 2mdk
  Copyright: BSD
  Group: Applications/Databases
  Source0: ftp://ftp.postgresql.org/pub/postgresql-%{version}.tar.gz
***************
*** 253,259 ****

## Removed the code for the data subpackage.

! mkdir -p $RPM_BUILD_ROOT/var/lib/pgsql

  # tests. There are many files included here that are unnecessary, but include
  # them anyway for completeness.
--- 253,259 ----

## Removed the code for the data subpackage.

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

# tests. There are many files included here that are unnecessary, but include
# them anyway for completeness.
***************
*** 387,393 ****
/usr/lib/pgsql/plpgsql.so
%attr(-,postgres,postgres) %dir /usr/lib/pgsql/backup
/usr/lib/pgsql/backup/pg_dumpall_new
! %attr(-,postgres,postgres) %dir /var/lib/pgsql

  %files devel
  %defattr(-,root,root)
--- 387,393 ----
  /usr/lib/pgsql/plpgsql.so
  %attr(-,postgres,postgres) %dir /usr/lib/pgsql/backup
  /usr/lib/pgsql/backup/pg_dumpall_new
! %attr(700,postgres,postgres) %dir /var/lib/pgsql

%files devel
%defattr(-,root,root)

--------------9701C623EF79D8ED423DA2DB--

From bouncefilter Tue Nov 23 10:32:08 1999
Received: from eclipse.pacifier.com (eclipse.pacifier.com [199.2.117.78])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA22969
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 10:31:12 -0500 (EST)
(envelope-from dhogaza@pacifier.com)
Received: from desktop (dsl-dhogaza.pacifier.net [216.65.147.68])
by eclipse.pacifier.com (8.9.3/8.9.3pop) with SMTP id HAA28787;
Tue, 23 Nov 1999 07:30:55 -0800 (PST)
Message-Id: <3.0.1.32.19991123072912.01027d30@mail.pacifier.com>
X-Sender: dhogaza@mail.pacifier.com
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 23 Nov 1999 07:29:12 -0800
To: Tom Lane <tgl@sss.pgh.pa.us>,
Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
From: Don Baccus <dhogaza@pacifier.com>
Subject: Re: [HACKERS] SQL statements: begin and end
Cc: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
In-Reply-To: <6087.943369194@sss.pgh.pa.us>
References: <Your message of Tue, 23 Nov 1999 11:31:04 +0100
<219F68D65015D011A8E000006F8590C603FDC184@sdexcsrv1.f000.d0188.sd.spardat.at>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 09:59 AM 11/23/99 -0500, Tom Lane wrote:

I went looking in the SQL spec to confirm this, and was rather
startled to discover that BEGIN is not SQL at all! The SQL spec
seems to envision the always-in-a-transaction-block model of operation.
They have
<commit statement> ::=
COMMIT [ WORK ]
which is defined to commit the current transaction; but a new xact is
implicitly started by the next SQL operation (cf. sec. 4.28 in SQL92).

This is how Oracle's SQL*Plus works.

If we wanted to be completely standards-conformant, I think we'd have to
abandon the begin/end model entirely. I wouldn't support that ---
auto commit of standalone statements is too convenient.

Oracle supports two modes, AFAIK (my Oracle experience is limited, but
not entirely non-existent). You can set it to autocommit mode. The
Tcl API I'm familiar with (for the web server AOLserver) works in
autocommit mode. You feed it a (guess what?) "BEGIN" dml statement
to switche off autocommit. Then you feed it a "COMMIT", it
commits the transaction, and tells Oracle to go back to autocommit mode.

Just like PostgreSQL...

Regarding the fact that SQL*Plus defaults to NOT auto-commit isn't
necessarily a bad thing, I might add - if you boo-boo when typing
in deletes and updates, forgetting an "and" clause perhaps, you
can type "abort". In psql, I always do a "begin" before doing any
deletes or updates to the database which backs my website, watching
to make sure that the number of rows changed or delted jives with
my expectation before committing.

I don't mind the way Postgres does stuff, though for someone used
to Oracle the fact that psql is autocommitting might come as an
unpleasant surprise.

Bottom line: pointing at the spec is a very weak argument for telling
people how to spell their begin/end statements.

Folks who do this should probably at least read the standard first.

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

From bouncefilter Tue Nov 23 10:38:08 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA24079
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 10:37:51 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA06310;
Tue, 23 Nov 1999 10:36:29 -0500 (EST)
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] SQL statements: begin and end
In-reply-to: Your message of Tue, 23 Nov 1999 15:16:58 +0000
<383AAFEA.29688B4F@alumni.caltech.edu>
Date: Tue, 23 Nov 1999 10:36:29 -0500
Message-ID: <6308.943371389@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

I'm pretty sure that Andrea's biggest objection was to the acceptance
and use of END, which has no connection in official SQL to transaction
completion but only to block delimiting for cursor loops. It is almost
certainly a holdover from PostQuel.

Any thoughts on whether AZ's suggestion for dropping END in this
context should be done for 7.0? We certainly could make an effort to
at least purge it from our examples in the docs...

Even AZ wasn't suggesting dropping it for 7.0!

We ought to check what other RDMSs are doing in this area before making
any decisions. The fact that we've got so many ways to spell "BEGIN"
suggests to me that some of them were tacked on for compatibility with
other products...

regards, tom lane

From bouncefilter Tue Nov 23 10:43:08 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 KAA25060
for <hackers@postgresql.org>; Tue, 23 Nov 1999 10:42:51 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id QAA152682;
Tue, 23 Nov 1999 16:42:33 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQYWC>; Tue, 23 Nov 1999 16:42:32 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC187@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'Don Baccus'" <dhogaza@pacifier.com>
Cc: "'hackers@postgresql.org'" <hackers@postgresql.org>
Subject: AW: [HACKERS] SQL statements: begin and end
Date: Tue, 23 Nov 1999 16:42:29 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

Bottom line: pointing at the spec is a very weak argument for telling
people how to spell their begin/end statements.

Folks who do this should probably at least read the standard first.

Ok, as I stated, I dislike the single "end" most. You are right that I
should have
checked the spec first. By standard I meant the common practice of other
DBMS's,
which is of course bad wording, Sorry.

Bottom line the "end" is evil, even in respect to SQL92 SQL98 ...

Andreas

From bouncefilter Tue Nov 23 11:16:09 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id LAA31626
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 11:15:19 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 23433 invoked by uid 1001); 23 Nov 1999 16:15:21 -0000
Date: Tue, 23 Nov 1999 11:15:21 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>,
"'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
Subject: Re: [HACKERS] SQL statements: begin and end
In-Reply-To: <6087.943369194@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.05.9911231108240.23191-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 23 Nov 1999, Tom Lane wrote:

My feeling is that application authors have already decided whether
they prefer "BEGIN" or "BEGIN TRANSACTION" or "BEGIN WORK", and trying
to enforce a single standard now is just going to irritate people and
break existing applications. I vote for leaving well enough alone.

Bruce, please don't use "begin" and "end" in your book.

Sure, it makes sense for the book to consistently use "BEGIN WORK"
and "COMMIT WORK", which are probably the least likely to confuse
novices. But I think actually removing the other variants would be
just an exercise in causing trouble.

I don't know how Oracle or most everyone else is doing it, but Sybase
uses:

begin transaction [transaction name]
and
commit transaction [transaction name]

I don't see an end transaction in the quick ref, but they do have a:

begin
statement block
end

in there.

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

From bouncefilter Tue Nov 23 11:41:10 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 LAA35910
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 11:41:00 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id RAA108484
for <pgsql-hackers@postgreSQL.org>; Tue, 23 Nov 1999 17:40:57 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQY83>; Tue, 23 Nov 1999 17:40:56 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC188@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] SQL statements: begin and end
Date: Tue, 23 Nov 1999 17:40:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

I don't see an end transaction in the quick ref, but they do have a:

begin
statement block
end

Which of course has nothing to do with transactions in Sybase :-)

Andreas

From bouncefilter Tue Nov 23 13:02:11 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA47338
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 13:01:31 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA06297;
Tue, 23 Nov 1999 13:01:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911231801.NAA06297@candle.pha.pa.us>
Subject: Re: AW: AW: [HACKERS] Getting OID in psql of recent insert
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC183@sdexcsrv1.f000.d0188.sd.spardat.at>
from Zeugswetter Andreas SEV at "Nov 23, 1999 09:58:08 am"
To: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
Date: Tue, 23 Nov 1999 13:01:02 -0500 (EST)
CC: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Yes, I use 'em the same way. I think an OID is kind of

like a pointer

in a C program: good for fast, unique access to an object

within the

context of the execution of a particular application (and maybe not
even that long). You don't write pointers into files to

be used again

by other programs, though, and in the same way an OID isn't a good
candidate for a long-lasting reference from one table to another.

I thought this special case is where the new xid access

method would come

in.

Good point, but (AFAIK) you could only use it for tables that you were
sure no other client was updating in parallel. Otherwise you might be
updating a just-obsoleted tuple. Or is there a solution for that?

Ok, the fact, that the row changed is known, because we can check the
snapshot. We also know, that the new row must be near the physical end
of the table, so maybe we could do a backward scan ?
Maybe we could also simply bail out, like Oracle with a "snapshot too old"
error message ?
(I know that this is not the same situation as the stated Oracle error)

That is too strange. If the tuple is superceeded, not sure how to
handle that. My guess is that we just let them access it. How do we
know if it is still a valid tuple in their own transaction? I am unsure
of this, though. Maybe there is a way to know.

Is someone still working on the xid access ?

I think we have the ability to refer to CTID in WHERE now,

Do we use the sql syntax 'where rowid = :xxx' for it,
or do we say 'where ctid = :xxx'.
I would like the rowid naming, because Informix, Oracle (and DB/2 ?) use it.

Is Informix rowid an actual physical row location. If so, it would be
nice to auto-rename the column references to ctid on input. Good idea.

but not yet an access method that actually makes it fast...

Well that is of course only half the fun :-(
Could it be done like an index access,
where the first part of the work is skipped, or tunneled through ?

They get the location they ask for, or a failure. Hunting around for
the new tuple seems like a real waste, and if someone vacuums, it is
gone, no?

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

From bouncefilter Tue Nov 23 13:04:10 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA47584
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 13:03:52 -0500 (EST)
(envelope-from alessio@albourne.com)
Received: from albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.8/MAPS) with ESMTP
id UAA13789; Tue, 23 Nov 1999 20:07:43 +0200 (EET)
Sender: alessio@albourne.com
Message-ID: <383AD704.C464CC26@albourne.com>
Date: Tue, 23 Nov 1999 20:03:48 +0200
From: Alessio Bragadini <alessio@albourne.com>
Organization: APL Financial Services (Overseas) Ltd.
X-Mailer: Mozilla 4.7 [en] (X11; I; OSF1 V4.0 alpha)
X-Accept-Language: it, en, sv
MIME-Version: 1.0
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
CC: Adriaan Joubert <a.joubert@albourne.com>
Subject: A bug or a feature?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We have a table with ~30 columns, named 'people' and we were going to
create a view for all record with 'relationship' equal to 1. The
database complains where using the '*' placeholder:

albourne=> CREATE VIEW employees AS SELECT * FROM people WHERE
relationship = 1;
ERROR: DefineQueryRewrite: rule plan string too big.

but accepts the same 30 columns on the command:

albourne=> create view employees as select
id,title,first_name,middle_name,last_name,suffix,company,job_title,address,city,zipcode,country,home_phone,home_fax,mobile,bus_phone,bus_fax,other_phone,e_mail_1,e_mail_2,url,birthday,christmas,brochure,golf,croquet,comment
from people where relationship=1;
CREATE

'*' is SQL92 (I think) so is this a bug or a known limitation?

The system is PostgreSQL 6.5.2 on alphaev6-dec-osf4.0f, compiled by cc.

Thanks
Alessio

--
Alessio F. Bragadini alessio@albourne.com
APL Financial Services http://www.sevenseas.org/~alessio
Nicosia, Cyprus phone: +357-2-750652

You are welcome, sir, to Cyprus. -- Shakespeare's "Othello"

From bouncefilter Tue Nov 23 13:05:10 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA47692
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 13:04:59 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA06490;
Tue, 23 Nov 1999 13:04:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911231804.NAA06490@candle.pha.pa.us>
Subject: Re: SQL statements: begin and end
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC184@sdexcsrv1.f000.d0188.sd.spardat.at>
from Zeugswetter Andreas SEV at "Nov 23, 1999 11:31:04 am"
To: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
Date: Tue, 23 Nov 1999 13:04:14 -0500 (EST)
CC: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgresql.org>,
"'Bruce Momjian'" <maillist@candle.pha.pa.us>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset iso-8859-1 unsupported, filtering to ASCII...]

I see everybody using the following PostgreSQL statements:

"begin" instead of "begin work"
"end" instead of "commit work"

This is really bad, because it is not standard, and can easily be taken for
a statement block, which it is definitely not ! It is a transaction block.

I vote for issuing a NOTICE for these in V7 and remove them in V8,
at least the single "end"

Not sure on this one. Why not let them use it?

Bruce, please don't use "begin" and "end" in your book.

OK.

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

From bouncefilter Tue Nov 23 13:27:10 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA52162
for <docs@postgreSQL.org>; Tue, 23 Nov 1999 13:26:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA07680;
Tue, 23 Nov 1999 13:24:46 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911231824.NAA07680@candle.pha.pa.us>
Subject: Re: [DOCS] RE: file name error (fwd)
In-Reply-To: <Pine.BSF.4.05.9911230533210.22824-100000@paprika.michvhf.com>
from Vince Vielhaber at "Nov 23, 1999 05:34:08 am"
To: Vince Vielhaber <vev@michvhf.com>
Date: Tue, 23 Nov 1999 13:24:46 -0500 (EST)
CC: docs@postgreSQL.org, wood@TuneStreet.com
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Forwarded from webmaster.

---------- Forwarded message ----------
Date: Mon, 22 Nov 1999 22:17:14 -0600
From: Brian D. Woodruff <wood@TuneStreet.com>
Subject: RE: file name error

ooh - sorry to be so vague! It's in a frame set, linked from Administration
in the Documentation section. The URL is:

http://postgresql.org/docs/admin/install761.htm

steps in the list which have problems are:

4, 6, 10, and 26

due to the "v" in the filename which is not in the filename on the FTP server.

other parts of the install process have incorrect paths, for instance, in
step 11, there is a change directory issued to:

/usr/src/pgsql/src/

which should really go to:

/usr/src/pgsql/postgresql-6.5.3/src/

This occurs in several places in the doc.

Apparently the path above is where the tar file puts things.

Other than that, the installation went well! This installation is on my
third server. Having fun with it :-)

You can see it in action on the order page of www.IncWay.com :-)

Again, I hope I'm being helpful! Thanks!

Thanks for the tips. The paths clearly needed fixing in many places.
The new version should appear on the website tomorrow.

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

From bouncefilter Tue Nov 23 14:13:11 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 OAA60185
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 14:13:01 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id UAA135588
for <pgsql-hackers@postgreSQL.org>; Tue, 23 Nov 1999 20:12:59 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQZKH>; Tue, 23 Nov 1999 20:12:59 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC189@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: AW: AW: [HACKERS] Getting OID in psql of recent insert
Date: Tue, 23 Nov 1999 20:12:49 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

Ok, the fact, that the row changed is known, because we can

check the

snapshot. We also know, that the new row must be near the

physical end

of the table, so maybe we could do a backward scan ?
Maybe we could also simply bail out, like Oracle with a

"snapshot too old"

error message ?
(I know that this is not the same situation as the stated

Oracle error)

That is too strange. If the tuple is superceeded, not sure how to
handle that. My guess is that we just let them access it. How do we
know if it is still a valid tuple in their own transaction?
I am unsure
of this, though. Maybe there is a way to know.

I think we do know, since when doing any seq scan we also have to know.

Do we use the sql syntax 'where rowid = :xxx' for it,
or do we say 'where ctid = :xxx'.
I would like the rowid naming, because Informix, Oracle

(and DB/2 ?) use it.

Is Informix rowid an actual physical row location.

Yes, it consists of page number and slot id, and is one integer.

Basically the same thing in Oracle.
How the value is printed is imho irrelevant, since it is not for the eye.

If so, it would be
nice to auto-rename the column references to ctid on input.
Good idea.

Andreas

From bouncefilter Tue Nov 23 14:22:11 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 OAA61475
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 14:22:04 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id UAA131228;
Tue, 23 Nov 1999 20:20:40 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQZK5>; Tue, 23 Nov 1999 20:20:40 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC18A@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'Bruce Momjian'" <pgman@candle.pha.pa.us>
Cc: "'pgsql-hackers@postgresql.org'" <pgsql-hackers@postgreSQL.org>
Subject: AW: [HACKERS] Re: SQL statements: begin and end
Date: Tue, 23 Nov 1999 20:20:32 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

I see everybody using the following PostgreSQL statements:

"begin" instead of "begin work"
"end" instead of "commit work"

This is really bad, because it is not standard, and can

easily be taken for

a statement block, which it is definitely not ! It is a

transaction block.

I vote for issuing a NOTICE for these in V7 and remove them in V8,
at least the single "end"

Not sure on this one. Why not let them use it?

1. It is actually already forbidden inside plpgsql, since there it is
a statement block, no ?
2. somebody stated, that is has a different meaning in embedded sql spec ?
(I did it again, have not checked :-()

I actually don't have strong feelings on this, just thought I'd bring it up,
cause it personally always misguides me.

Andreas

From bouncefilter Tue Nov 23 14:30:12 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 OAA62447
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 14:29:13 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id UAA218236
for <pgsql-hackers@postgresql.org>; Tue, 23 Nov 1999 20:29:11 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQZL1>; Tue, 23 Nov 1999 20:29:11 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC18B@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'pgsql-hackers@postgreSQL.org'" <pgsql-hackers@postgresql.org>
Subject: AW: AW: AW: [HACKERS] Getting OID in psql of recent insert
Date: Tue, 23 Nov 1999 20:29:11 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

They get the location they ask for, or a failure. Hunting around for
the new tuple seems like a real waste, and if someone vacuums, it is
gone, no?

It is probably worse, since they might even get the wrong row,
but that's the same in Informix and Oracle.

In Informix:

a: selects rowid
b: updates row, row grows, does not fit in page, is relocated
c: inserts rows, pysical location of rowid is reused
a: selects row by rowid, gets differet row --> bummer

Andreas

From bouncefilter Tue Nov 23 15:07:15 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 PAA68796
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 15:07:02 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id OAA29389;
Tue, 23 Nov 1999 14:42:39 -0500
Message-ID: <383AEE26.3F1372F7@wgcr.org>
Date: Tue, 23 Nov 1999 14:42:30 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
Subject: Re: Mandrake RPMs (was RPM build on Suse linux 6.2)
References: <199911221747.MAA04455@candle.pha.pa.us>
<38398D73.8D466F32@wgcr.org> <383A0120.708B68BF@alumni.caltech.edu>
<99112223350202.00597@lorc.wgcr.org>
<383AB226.B0FBCB67@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thomas Lockhart wrote:

They last put in 6.5.2-1 in Cooker. And Cooker has the src.rpm.

I'm just using yours for now. Interesting: on my new laptop it builds
*i686* rpms, since the Mandrake /usr/lib/rpm/rpmrc is very aggressive
about matching the build machine. I have created a /root/.rpmrc to
override this, but I'm planning on posting some optimized RPMs at
postgresql.org.

Sounds good. Yeah, Mandrake has been quite aggressive on the CPU
optimization front -- however, I still have some 486's running here, so
the i386 binaries work for me. If we want to distribute i586 and i686
versions, I have no complaints.

I looked at the Mandrake Cooker spec file -- and there are differences
all over the place -- most noticeably in the truncation of the
Changelog. The most notable difference is in the use of bzip2 to
compress the man pages.

We might also want to consider building some non-locale-enabled RPMs
so folks can get the speed boost if they aren't using non-ascii
English.

On my TODO list for the next RPM release (which is looking to be sooner
than I had expected....).

I've changed a couple of lines in the spec file; diffs included below.

Looks familiar -- fixing the permissions bug, and bumping the version.

Can you forward Mandrake's reply to me??

Sure. Haven't heard from them yet...

Thanks. I had e-mailed Axalon Bloodstone directly, as he did the
packaging for the Cooker RPM.

Also, Jef and I got the RPM's built, installed, and running under SuSE
6.2. I'm going to put up a page on ramifordistat detailing the steps and
packages needed. Man, SuSE is far different from RedHat!
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11

From bouncefilter Tue Nov 23 14:57:15 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id OAA66890
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 14:57:02 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 24096 invoked by uid 1001); 23 Nov 1999 19:57:05 -0000
Message-ID: <XFMail.991123145705.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC188@sdexcsrv1.f000.d0188.sd.spardat.at>
Date: Tue, 23 Nov 1999 14:57:05 -0500 (EST)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
Subject: RE: AW: [HACKERS] SQL statements: begin and end
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgreSQL.org>

On 23-Nov-99 Zeugswetter Andreas SEV wrote:

I don't see an end transaction in the quick ref, but they do have a:

begin
statement block
end

Which of course has nothing to do with transactions in Sybase :-)

statement block != transactions I didn't think I even implied that.
What I was pointing out was that Sybase ... why bother explaining.

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

From bouncefilter Tue Nov 23 15:03:12 1999
Received: from charleston.softhome.net (qmailr@charleston.SoftHome.net
[204.144.231.41]) by hub.org (8.9.3/8.9.3) with SMTP id PAA67945
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 15:02:51 -0500 (EST)
(envelope-from j.roeleveld@softhome.net)
Received: (qmail 22458 invoked by uid 417); 23 Nov 1999 20:31:51 -0000
Received: from p3357.nl.wish.net (HELO galaxy.galnet) (212.123.151.29)
by smtp.softhome.net with SMTP; 23 Nov 1999 20:31:51 -0000
Message-Id: <4.1.19991123205210.00924b20@pop.softhome.net>
X-Sender: j.roeleveld@pop.softhome.net
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1
Date: Tue, 23 Nov 1999 20:57:40 +0100
To: pgsql-hackers@postgresql.org
From: "J. Roeleveld" <j.roeleveld@softhome.net>
Subject: Fwd: [GENERAL] Problem with CREATE RULE <something> ON DELETE
(PostgreSQL only executes the first expression)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi,

I'm reposting it here, since i haven't received any help after posting it
at the general
mailing-list, and sending in a bug-report at the bugs mailing-list.

I'm willing to forward the bug-report to any email-adress I'm asked for to
sent it to,
but since it's a long one (contains a full script to reproduce this error)
I'm a bit reluctant
to do so.

Joost Roeleveld

=========== Forwarded Message follows ==========
Hi,

I have found what appears to be a bug in PostgreSQL, or is this a feature?
I don't think it's a feature, because the postgreSQL documentation state it
should work.

When creating delete-rules for views, i have found that only the first
expression is being executed, when
using multiple expressions.

I have managed to do this for Insert, and i think for Update as well...
although i haven't gotten around to testing that yet.

The following is the RULE-definition I use, it's for a View (
bedrijven_view ) which consists of
two tables ( adressen_table and bedrijven_table ).
When I change the sequence (eg. put the delete from bedrijven_table first)
it still only does the first statement.

CREATE RULE delete_bedrijven_view AS ON DELETE
TO bedrijven_view
DO INSTEAD (
DELETE FROM adressen_table
WHERE adres_id = get_adres_nummer(straatnaam,
huisnummer,postcode,land);
DELETE FROM bedrijven_table
WHERE firma_id = firma_id;
);

If you require more information, for instance a full list of statements
that can reproduce the problem,
please let me know, and I'll forward the bug-report I sent in yesterday
morning.

with kind regards,

Joost Roeleveld

From bouncefilter Tue Nov 23 15:00:11 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA67214
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 14:59:24 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA11605;
Tue, 23 Nov 1999 14:58:47 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911231958.OAA11605@candle.pha.pa.us>
Subject: Re: AW: [HACKERS] Getting OID in psql of recent insert
In-Reply-To: <383AE26F.831E5434@tpf.co.jp> from Hiroshi Inoue at "Nov 24, 1999
03:52:31 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Tue, 23 Nov 1999 14:58:47 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Good point, but (AFAIK) you could only use it for tables that you were
sure no other client was updating in parallel. Otherwise you might be
updating a just-obsoleted tuple. Or is there a solution for that?

Is someone still working on the xid access ?

I think we have the ability to refer to CTID in WHERE now, but not yet an
access method that actually makes it fast...

Hiroshi supplied a patch to allow it in the executor, and I applied it.

Bruce,could you apply my attached patch ?
I have to add 3 new files but couldn't do 'cvs add'
the files on my machine.
Am I mistaken ?
I couldn't understand the reason now.

Applied. No idea why the add didn't work there. It worked here.

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

From bouncefilter Tue Nov 23 16:20:12 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 QAA79643
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 16:19:23 -0500 (EST)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH1 with Internet Mail Service (5.5.2448.0)
id <X3ZP2L3N>; Tue, 23 Nov 1999 23:17:35 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C2B4@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Vince Vielhaber '" <vev@michvhf.com>, "'Zeugswetter Andreas SEV '"
<ZeugswetterA@wien.spardat.at>
Cc: "'pgsql-hackers@postgresql.org '" <pgsql-hackers@postgreSQL.org>
Subject: RE: AW: [HACKERS] SQL statements: begin and end
Date: Tue, 23 Nov 1999 22:57:29 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

Which of course has nothing to do with transactions in Sybase :-)

statement block != transactions I didn't think I even implied that.
What I was pointing out was that Sybase ... why bother explaining.

Vince.

Vince, I suspect that Andreas knew exactly what you meant ;-)

From bouncefilter Tue Nov 23 17:19:39 1999
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net
[194.217.242.39]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA86979
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 17:19:09 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
id 11qOH4-000IZc-0B; Tue, 23 Nov 1999 22:18:58 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id WAA07783; Tue, 23 Nov 1999 22:18:53 GMT
Message-Id: <199911232218.WAA07783@mtcc.demon.co.uk>
Date: Tue, 23 Nov 1999 22:18:53 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] VACUUM as a denial-of-service attack
To: pgsql-hackers@postgresql.org, tgl@sss.pgh.pa.us
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY=Scraw_of_Flies_653_000
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

--Scraw_of_Flies_653_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: uaNuTdLMkpxPCr3r+tp3wg==

From: Tom Lane <tgl@sss.pgh.pa.us>
I think a reasonable answer to this is to restrict VACUUM on any
table to be allowed only to the table owner and Postgres superuser.
Does anyone have an objection or better idea?

In the dim and distant past I produced a patch that put vacuum
into the list of things that you could GRANT on a per-table
basis. I don't know what effort it would take to rework that
for current or if it would be worth it.

I think your suggestion above would be perfect if you never
need to allow anyone else to vacuum a table.

I'va attached the old patch below.

Keith.

--Scraw_of_Flies_653_000
Content-Type: TEXT/plain; name="oldvacacl.diff"; charset=us-ascii;
x-unix-mode=0644
Content-Description: oldvacacl.diff
Content-MD5: CA1EAwKAbw2e93NeIp2MCw==

*** backend/parser/gram.y.orig	Thu May 22 18:16:19 1997
--- backend/parser/gram.y	Thu May 22 18:18:22 1997
***************
*** 646,656 ****

  privileges:  ALL PRIVILEGES
  		{
! 		 $$ = aclmakepriv("rwaR",0);
  		}
             | ALL
  		{
! 		 $$ = aclmakepriv("rwaR",0);
  		}
             | operation_commalist {
  		$$ = $1;
--- 646,656 ----

  privileges:  ALL PRIVILEGES
  		{
! 		 $$ = aclmakepriv("rwaRv",0);
  		}
             | ALL
  		{
! 		 $$ = aclmakepriv("rwaRv",0);
  		}
             | operation_commalist {
  		$$ = $1;
***************
*** 681,686 ****
--- 681,689 ----
  		}
  	    | RULE {
  		$$ = ACL_MODE_RU_CHR;
+ 		}
+ 	    | VACUUM {
+ 		$$ = ACL_MODE_VA_CHR;
  		}
              ;

*** backend/tcop/aclchk.c.orig	Thu May 22 18:18:43 1997
--- backend/tcop/aclchk.c	Thu May 22 18:25:07 1997
***************
*** 32,37 ****
--- 32,38 ----
  #include "catalog/pg_aggregate.h"
  #include "catalog/pg_proc.h"
  #include "catalog/pg_user.h"
+ #include "catalog/pg_database.h"
  #include "utils/syscache.h"
  #include "parser/catalog_utils.h"
  #include "fmgr.h"
***************
*** 62,68 ****
    "No error.",
    "Permission denied.",
    "Table does not exist.",
!   "Must be table owner."
  };

  #ifdef ACLDEBUG_TRACE
--- 63,70 ----
    "No error.",
    "Permission denied.",
    "Table does not exist.",
!   "Must be table owner.",
!   "Must be database dba."
  };

  #ifdef ACLDEBUG_TRACE
***************
*** 514,525 ****
--- 516,537 ----
  		 NAMEDATALEN, value);
  	owner_id = ((TypeTupleForm) GETSTRUCT(htp))->typowner;
  	break;
+     case DATABASEN:
+ 	if (!HeapTupleIsValid(htp))
+ 	    elog(WARN, "pg_ownercheck: database \"%-.*s\" not found",
+ 		NAMEDATALEN, value);
+ 	owner_id = ((Form_pg_database) GETSTRUCT(htp))->datdba;
+ 	break;
      default:
  	elog(WARN, "pg_ownercheck: invalid cache id: %d",
  	     cacheid);
  	break;
      }

+ #ifdef ACLDEBUG_TRACE
+     elog(DEBUG, "pg_ownercheck: user = %d owner = %d", user_id, owner_id);
+ #endif
+ 
      return(user_id == owner_id);
  }

*** backend/tcop/utility.c.orig	Thu May 22 18:25:23 1997
--- backend/tcop/utility.c	Thu May 22 18:33:04 1997
***************
*** 614,625 ****
--- 614,644 ----
  	break;

      case T_VacuumStmt:
+ 	{
+ 	    int		aclcheck_result;
+ 	    char*	dbasename;
+ 	    VacuumStmt	*stmt = (VacuumStmt *)parsetree;
+ 
+ #ifndef NO_SECURITY
+ 	    relname = stmt->vacrel;
+ 	    if (relname != NULL) {
+ 		aclcheck_result = pg_aclcheck(relname, userName, ACL_VA);
+ 		if(aclcheck_result != ACLCHECK_OK)
+ 		    elog(WARN, "%s: %s", relname, aclcheck_error_strings[aclcheck_result]);
+ 	    } else {	/* Need to check we own the DB for a full vacuum */
+ 		dbasename = GetDatabaseName();
+ 		if (!pg_ownercheck(userName, dbasename, DATABASEN))
+ 		    elog(WARN, "%s: %s", dbasename, aclcheck_error_strings[ACLCHECK_NOT_DBA]);
+ 		}
+ #endif
+ 
  	commandTag = "VACUUM";
  	CHECK_IF_ABORTED();
  	vacuum( ((VacuumStmt *) parsetree)->vacrel,
  		((VacuumStmt *) parsetree)->verbose,
  		((VacuumStmt *) parsetree)->analyze,
  		((VacuumStmt *) parsetree)->va_spec);
+ 	}
  	break;

      case T_ExplainStmt:
*** backend/utils/adt/acl.c.orig	Sat May 10 21:25:18 1997
--- backend/utils/adt/acl.c	Sun May 11 22:27:58 1997
***************
*** 66,72 ****
  /*
   * aclparse
   *	Consumes and parses an ACL specification of the form:
!  *		[group|user] [A-Za-z0-9]*[+-=][rwaR]*
   *	from string 's', ignoring any leading white space or white space
   *	between the optional id type keyword (group|user) and the actual
   *	ACL specification.
--- 66,72 ----
  /*
   * aclparse
   *	Consumes and parses an ACL specification of the form:
!  *		[group|user] [A-Za-z0-9]*[+-=][rwaRv]*
   *	from string 's', ignoring any leading white space or white space
   *	between the optional id type keyword (group|user) and the actual
   *	ACL specification.
***************
*** 123,128 ****
--- 123,129 ----
  	case ACL_MODE_RD_CHR: aip->ai_mode |= ACL_RD; break;
  	case ACL_MODE_WR_CHR: aip->ai_mode |= ACL_WR; break;
  	case ACL_MODE_RU_CHR: aip->ai_mode |= ACL_RU; break;
+ 	case ACL_MODE_VA_CHR: aip->ai_mode |= ACL_VA; break;
  	default:  elog(WARN, "aclparse: mode flags must use \"%s\"",
  		       ACL_MODE_STR);
  	}
***************
*** 517,524 ****
      int i;
      int l;

! Assert(strlen(old_privlist)<5);
! priv = malloc(5); /* at most "rwaR" */;

      if (old_privlist == NULL || old_privlist[0] == '\0') {
  	priv[0] = new_priv;
--- 518,525 ----
      int i;
      int l;

! Assert(strlen(old_privlist)<(N_ACL_MODES+1));
! priv = malloc(N_ACL_MODES+1); /* at most N_ACL_MODES */;

if (old_privlist == NULL || old_privlist[0] == '\0') {
priv[0] = new_priv;
***************
*** 530,536 ****

l = strlen(old_privlist);

! if (l == 4) { /* can't add any more privileges */
return priv;
}

--- 531,537 ----

l = strlen(old_privlist);

! if (l == N_ACL_MODES) { /* can't add any more privileges */
return priv;
}

*** backend/utils/cache/syscache.c.orig	Sun May 11 12:59:32 1997
--- backend/utils/cache/syscache.c	Sun May 11 20:23:39 1997
***************
*** 45,50 ****
--- 45,51 ----
  #include "catalog/pg_operator.h"
  #include "catalog/pg_proc.h"
  #include "catalog/pg_class.h"
+ #include "catalog/pg_database.h"
  #include "catalog/pg_type.h"
  #include "catalog/pg_rewrite.h"
  #include "catalog/pg_aggregate.h"
***************
*** 315,320 ****
--- 316,330 ----
                    0,
                    0 },
  	   sizeof(FormData_pg_opclass),
+            NULL,
+            (ScanFunc) NULL   },
+     { DatabaseRelationName,               /* DATABASEN */
+ 	   1,
+   	   { Anum_pg_database_datname,
+                   0,
+                   0,
+                   0 },
+ 	   sizeof(FormData_pg_database),
             NULL,
             (ScanFunc) NULL   }
  };
*** include/utils/acl.h.orig	Thu May 22 18:33:30 1997
--- include/utils/acl.h	Thu May 22 18:43:16 1997
***************
*** 52,58 ****
  #define	ACL_RD		(1<<1)	/* read */
  #define	ACL_WR		(1<<2)	/* write (append/delete/replace) */
  #define	ACL_RU		(1<<3)	/* place rules */
! #define	N_ACL_MODES	4

  #define	ACL_MODECHG_ADD		1
  #define	ACL_MODECHG_DEL		2
--- 52,59 ----
  #define	ACL_RD		(1<<1)	/* read */
  #define	ACL_WR		(1<<2)	/* write (append/delete/replace) */
  #define	ACL_RU		(1<<3)	/* place rules */
! #define	ACL_VA		(1<<4)	/* vacuum */
! #define	N_ACL_MODES	5

#define ACL_MODECHG_ADD 1
#define ACL_MODECHG_DEL 2
***************
*** 61,67 ****
/* change this line if you want to set the default acl permission */
#define ACL_WORLD_DEFAULT (ACL_RD)
/* #define ACL_WORLD_DEFAULT (ACL_RD|ACL_WR|ACL_AP|ACL_RU) */
! #define ACL_OWNER_DEFAULT (ACL_RD|ACL_WR|ACL_AP|ACL_RU)

  /*
   * AclItem
--- 62,68 ----
  /* change this line if you want to set the default acl permission  */
  #define	ACL_WORLD_DEFAULT	(ACL_RD)
  /* #define	ACL_WORLD_DEFAULT	(ACL_RD|ACL_WR|ACL_AP|ACL_RU) */
! #define	ACL_OWNER_DEFAULT	(ACL_RD|ACL_WR|ACL_AP|ACL_RU|ACL_VA)

/*
* AclItem
***************
*** 105,121 ****
#define ACL_MODECHG_ADD_CHR '+'
#define ACL_MODECHG_DEL_CHR '-'
#define ACL_MODECHG_EQL_CHR '='
! #define ACL_MODE_STR "arwR" /* list of valid characters */
#define ACL_MODE_AP_CHR 'a'
#define ACL_MODE_RD_CHR 'r'
#define ACL_MODE_WR_CHR 'w'
#define ACL_MODE_RU_CHR 'R'

/* result codes for pg_aclcheck */
#define ACLCHECK_OK 0
#define ACLCHECK_NO_PRIV 1
#define ACLCHECK_NO_CLASS 2
#define ACLCHECK_NOT_OWNER 3

  /* warning messages.  set these in aclchk.c. */
  extern char *aclcheck_error_strings[];
--- 106,124 ----
  #define	ACL_MODECHG_ADD_CHR	'+'
  #define	ACL_MODECHG_DEL_CHR	'-'
  #define	ACL_MODECHG_EQL_CHR	'='
! #define	ACL_MODE_STR		"arwRv"	/* list of valid characters */
  #define	ACL_MODE_AP_CHR		'a'
  #define	ACL_MODE_RD_CHR		'r'
  #define	ACL_MODE_WR_CHR		'w'
  #define	ACL_MODE_RU_CHR		'R'
+ #define ACL_MODE_VA_CHR		'v' /* If you add a mode don't forget to change N_ACL_MODES */

/* result codes for pg_aclcheck */
#define ACLCHECK_OK 0
#define ACLCHECK_NO_PRIV 1
#define ACLCHECK_NO_CLASS 2
#define ACLCHECK_NOT_OWNER 3
+ #define ACLCHECK_NOT_DBA 4

  /* warning messages.  set these in aclchk.c. */
  extern char *aclcheck_error_strings[];
*** include/utils/syscache.h.orig	Sun May 11 13:19:12 1997
--- include/utils/syscache.h	Sun May 11 13:20:42 1997
***************
*** 59,64 ****
--- 59,65 ----
  #define	REWRITENAME	25
  #define PROSRC          26
  #define CLADEFTYPE      27
+ #define DATABASEN       28

  /* ----------------
   *	struct cachedesc:	information needed for a call to InitSysCache()
*** bin/psql/psqlHelp.h.orig	Thu May 22 18:43:41 1997
--- bin/psql/psqlHelp.h	Fri May 23 15:32:48 1997
***************
*** 136,142 ****
        "fetch [forward|backward] [<number>|all] [in <cursorname>];"},
    { "grant",
        "grant access control to a user or group",
!       "grant <privilege[,privilege,...]> on <rel1>[,...<reln>] to \n[public | group <group> | <username>]\n\t privilege is {ALL | SELECT | INSERT | UPDATE | DELETE | RULE}"},
    { "insert",
        "insert tuples",
        "insert into <class_name> [(<attr1>...<attrN>)]\n\t[values (<expr1>...<exprN>); |\n\tselect <expr1>,...<exprN> [from <from_clause>] [where <qual>];"},
--- 136,142 ----
        "fetch [forward|backward] [<number>|all] [in <cursorname>];"},
    { "grant",
        "grant access control to a user or group",
!       "grant <privilege[,privilege,...]> on <rel1>[,...<reln>] to \n[public | group <group> | <username>]\n\t privilege is {ALL | SELECT | INSERT | UPDATE | DELETE | RULE | VACUUM}"},
    { "insert",
        "insert tuples",
        "insert into <class_name> [(<attr1>...<attrN>)]\n\t[values (<expr1>...<exprN>); |\n\tselect <expr1>,...<exprN> [from <from_clause>] [where <qual>];"},
***************
*** 157,163 ****
        "reset {DateStyle | GEQO}"},
    { "revoke",
        "revoke access control from a user or group",
!       "revoke <privilege[,privilege,...]> on <rel1>[,...<reln>] from \n[public | group <group> | <username>]\n\t privilege is {ALL | SELECT | INSERT | UPDATE | DELETE | RULE}"},
    { "rollback",
        "abort a transaction",
        "rollback [transaction|work]"},
--- 157,163 ----
        "reset {DateStyle | GEQO}"},
    { "revoke",
        "revoke access control from a user or group",
!       "revoke <privilege[,privilege,...]> on <rel1>[,...<reln>] from \n[public | group <group> | <username>]\n\t privilege is {ALL | SELECT | INSERT | UPDATE | DELETE | RULE | VACUUM}"},
    { "rollback",
        "abort a transaction",
        "rollback [transaction|work]"},
*** man/grant.l.orig	Mon May 12 08:18:55 1997
--- man/grant.l	Mon May 12 08:20:15 1997
***************
*** 10,16 ****
  	\fBon\fR <rel1>[,...<reln>]
  	\fBto\fR [\fBpublic\fR | group <group> | <username>]

! 	\fBprivilege\fR is {\fBALL\fR | \fBSELECT\fR | \fBINSERT\fR | \fBUPDATE\fR | \fBDELETE\fR | \fBRULE\fR}
  .fi
  .SH DESCRIPTION
  .PP
--- 10,16 ----
  	\fBon\fR <rel1>[,...<reln>]
  	\fBto\fR [\fBpublic\fR | group <group> | <username>]

! 	\fBprivilege\fR is {\fBALL\fR | \fBSELECT\fR | \fBINSERT\fR | \fBUPDATE\fR | \fBDELETE\fR | \fBRULE\fR | \fBVACUUM\R}
  .fi
  .SH DESCRIPTION
  .PP
*** man/revoke.l.orig	Mon May 12 08:19:14 1997
--- man/revoke.l	Mon May 12 08:20:42 1997
***************
*** 10,16 ****
  	\fBon\fR <rel1>[,...<reln>]
  	\fBfrom\fR [\fBpublic\fR | group <group> | <username>]

! 	\fBprivilege\fR is {\fBALL\fR | \fBSELECT\fR | \fBINSERT\fR | \fBUPDATE\fR | \fBDELETE\fR | \fBRULE\fR}
  .fi
  .SH DESCRIPTION
  .PP
--- 10,16 ----
  	\fBon\fR <rel1>[,...<reln>]
  	\fBfrom\fR [\fBpublic\fR | group <group> | <username>]

! 	\fBprivilege\fR is {\fBALL\fR | \fBSELECT\fR | \fBINSERT\fR | \fBUPDATE\fR | \fBDELETE\fR | \fBRULE\fR | \fBVACUUM\R}
  .fi
  .SH DESCRIPTION
  .PP
*** man/vacuum.l.orig	Thu May 22 18:47:54 1997
--- man/vacuum.l	Thu May 22 18:56:00 1997
***************
*** 1,7 ****
  .\" This is -*-nroff-*-
  .\" XXX standard disclaimer belongs here....
  .\" $Header: /usr/local/cvsroot/postgres95/src/man/vacuum.l,v 1.4 1997/05/13 04:41:54 momjian Exp $
! .TH VACUUM SQL 11/05/95 PostgreSQL PostgreSQL
  .SH NAME
  vacuum \(em vacuum a database
  .SH SYNOPSIS
--- 1,7 ----
  .\" This is -*-nroff-*-
  .\" XXX standard disclaimer belongs here....
  .\" $Header: /usr/local/cvsroot/postgres95/src/man/vacuum.l,v 1.4 1997/05/13 04:41:54 momjian Exp $
! .TH VACUUM SQL 22/05/97 PostgreSQL PostgreSQL
  .SH NAME
  vacuum \(em vacuum a database
  .SH SYNOPSIS
***************
*** 40,44 ****
  .PP
  The purge(l) command can be used to control the archive retention
  characteristics of a given table.
  .SH "SEE ALSO"
! purge(l).
--- 40,53 ----
  .PP
  The purge(l) command can be used to control the archive retention
  characteristics of a given table.
+ .PP
+ Only the database owner (DBA) is allowed to vacuum the whole database.
+ Table vacuum rights may be granted to or revoked from individual users
+ with the
+ .BR grant(l)
+ and
+ .BR revoke(l)
+ commands.
+ 
  .SH "SEE ALSO"
! purge(l) grant(l) revoke(l).

--Scraw_of_Flies_653_000--

From bouncefilter Tue Nov 23 20:30:40 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 UAA09820
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 20:29:53 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA11932;
Tue, 23 Nov 1999 19:44:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911240044.TAA11932@candle.pha.pa.us>
Subject: Cache on pg_statistics
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Tue, 23 Nov 1999 19:44:02 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom, let me know what caches you want on pg_statistics, or if you would
prefer to do it yourself, instructions are at the top of syscache.c.

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

From bouncefilter Tue Nov 23 19:56:15 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA04174
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 19:55:51 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63767 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sCnS4231844>; Wed, 24 Nov 1999 01:55:34 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11qQjj-00009B-00; Wed, 24 Nov 1999 01:56:43 +0100
Date: Wed, 24 Nov 1999 01:56:43 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
cc: "'PostgreSQL-development'" <pgsql-hackers@postgresql.org>
Subject: Re: AW: [HACKERS] Getting OID in psql of recent insert
In-Reply-To:
<219F68D65015D011A8E000006F8590C603FDC181@sdexcsrv1.f000.d0188.sd.spardat.at>
Message-ID: <Pine.LNX.4.20.9911222254330.417-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 1999-11-22, Zeugswetter Andreas SEV mentioned:

testdb=> \set singlestep on
testdb=> \set sql_interpol '#'
testdb=> \set foo 'pg_class'
testdb=> select * from #foo#;

This is great, but may I object to the syntax ?
The standard sql way to use host variables seems to be:
select * from :foo where id = :id

There will always be the problem with conflicting operators,
and this one syntax, already needed by ecpg, it is hard enough.

I just pulled that syntax out of my hat, since it was the most
non-interfering way to go for now, but thanks for the tip, I'll be on the
task in a second. Of course, since the SQL standard is such a widely
available document, I should have found that myself ;)

Is there also a rule on what those variables can contain? I mean currently
they act like C macros, they can contain unbalances quotes, incomplete
backslash commands, everything. Or should they be restricted to SQL?

Also, looking for possible conflicts here, it seems that there is an
operator ':' for exponentiation, which is of course extremely mnemonic.
This reminds me of the ';' operator for logarithms, which I also use all
the time in mathematical writing. Are those operators actually standard or
just somebody's personal idea?

For example, what does this mean:
play=> select value, :value from test;
value | ?column?
-------+----------------------
5 | 148.413159102577
6 | 403.428793492735
99 | 9.88903031934695e+42
(3 rows)

Similarly for the ';' operator, where there are obvious problems.
Rationale anybody? Are they from PostQUEL times?

Um, okay, this goes even further. There seem to be functions called log
and dlog1 as well as exp and dexp with essentially the same functionality;
the one with the 'd' goes with float8 arguments, the other one with
numeric. Is this making sense to anybody?

-Peter

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

From bouncefilter Tue Nov 23 20:22:15 1999
Received: from ext16.sra.co.jp (IDENT:root@ykh28DS39.kng.mesh.ad.jp
[133.205.214.39]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA08456
for <pgsql-hackers@postgresql.org>;
Tue, 23 Nov 1999 20:22:08 -0500 (EST)
(envelope-from t-ishii@ext16.sra.co.jp)
Received: from ext16.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id KAA01706
for <pgsql-hackers@postgresql.org>; Wed, 24 Nov 1999 10:15:09 +0900
Message-Id: <199911240115.KAA01706@ext16.sra.co.jp>
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: pgsql-hackers@postgresql.org
Subject: lztext.c
Date: Wed, 24 Nov 1999 10:15:09 +0900
Sender: t-ishii@ext16.sra.co.jp

I'm going to commit changes to make lztextlen() aware of
multi-byte. While doing the work, I found that no POSITION() or
SUBSTRING() for lztext has been implemented in the file.

BTW, does anybody work on making lztext indexable? If no, I will take
care of it with above addtions.
--
Tatsuo Ishii

From bouncefilter Tue Nov 23 20:33:15 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA10405
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 20:32:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA13582;
Tue, 23 Nov 1999 20:31:45 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911240131.UAA13582@candle.pha.pa.us>
Subject: Re: AW: [HACKERS] Getting OID in psql of recent insert
In-Reply-To: <Pine.LNX.4.20.9911222254330.417-100000@localhost.localdomain>
from Peter Eisentraut at "Nov 24, 1999 01:56:43 am"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Tue, 23 Nov 1999 20:31:45 -0500 (EST)
CC: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>,
"'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Is there also a rule on what those variables can contain? I mean currently
they act like C macros, they can contain unbalances quotes, incomplete
backslash commands, everything. Or should they be restricted to SQL?

Also, looking for possible conflicts here, it seems that there is an
operator ':' for exponentiation, which is of course extremely mnemonic.
This reminds me of the ';' operator for logarithms, which I also use all
the time in mathematical writing. Are those operators actually standard or
just somebody's personal idea?

I recommend we rename : and ; to something else. : should be used for
variables, and ; is too much like the trailing semicolon.

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

From bouncefilter Tue Nov 23 21:35:17 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id VAA17849
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 21:35:00 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11qS8T-0003kGC; Wed, 24 Nov 99 03:26 MET
Message-Id: <m11qS8T-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] lztext.c
To: t-ishii@sra.co.jp (Tatsuo Ishii)
Date: Wed, 24 Nov 1999 03:26:21 +0100 (MET)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199911240115.KAA01706@ext16.sra.co.jp> from "Tatsuo Ishii" at
Nov 24, 99 10:15:09 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Tatsuo Ishii wrote:

I'm going to commit changes to make lztextlen() aware of
multi-byte. While doing the work, I found that no POSITION() or
SUBSTRING() for lztext has been implemented in the file.

Thank's for that. I usually don't have multi-byte support
compiled in and it's surely better if you do the extension
and tests.

I know that a lot of functions are missing so far. Especially
comparision and the mentioned ones. I thought to get back on
it after the multi-byte support is inside.

BTW, does anybody work on making lztext indexable? If no, I will take
care of it with above addtions.

IMHO something questionable.

A compressed data type is preferred to store large amounts of
data. Indexing large fields OTOH is something to prevent by
database design. The new type at hand offers reasonable
compression rates only above some size of input.

OTOOH, it might get someone around the btree split problems
some of us encountered and which I where able to trigger with
field contents above 2K already. In such a case it can be a
last resort.

I'd like to know what others think.

Don't spend much efford for comparision and the SUBSTRING()
things right now. I already have an additional, generalized
decompressor in mind, that can be used in the comparision for
example to decompress two values on the fly and stop
comparision at the first difference, which usually happens
early in two random datums.

Tell me when you have the multi-byte (and maybe cyrillic?)
stuff committed and I'll take my hands back on the code.

Jan

--

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

From bouncefilter Tue Nov 23 21:45:16 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 VAA19316
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 21:45:01 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11qSI5-0003kGC; Wed, 24 Nov 99 03:36 MET
Message-Id: <m11qSI5-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] A bug or a feature?
To: alessio@albourne.com (Alessio Bragadini)
Date: Wed, 24 Nov 1999 03:36:17 +0100 (MET)
Cc: pgsql-hackers@postgreSQL.org, a.joubert@albourne.com
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <383AD704.C464CC26@albourne.com> from "Alessio Bragadini" at Nov
23, 99 08:03:48 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Alessio F. Bragadini wrote:

We have a table with ~30 columns, named 'people' and we were going to
create a view for all record with 'relationship' equal to 1. The
database complains where using the '*' placeholder:

albourne=> CREATE VIEW employees AS SELECT * FROM people WHERE
relationship = 1;
ERROR: DefineQueryRewrite: rule plan string too big.

but accepts the same 30 columns on the command:

[...]

'*' is SQL92 (I think) so is this a bug or a known limitation?

The system is PostgreSQL 6.5.2 on alphaev6-dec-osf4.0f, compiled by cc.

It's a well known limitation in versions up to 6.5.*.

I've lowered the problem in the 7.0 tree by compressing the
rule plan string, using a new data type. A 'SELECT *' view
from a table with 54 fields uses only about 25% of the
available space then.

Jan

--

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

From bouncefilter Tue Nov 23 22:18:18 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 WAA23254;
Tue, 23 Nov 1999 22:17:21 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id DAA30433;
Wed, 24 Nov 1999 03:18:25 GMT
Sender: lockhart@hub.org
Message-ID: <383B5900.59BBB74D@alumni.caltech.edu>
Date: Wed, 24 Nov 1999 03:18:24 +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: Postgres Documentation List <docs@postgresql.org>,
Postgres Hackers List <hackers@postgresql.org>
Subject: From the LDP web site...
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

(from www.linuxdoc.org)

Latest News:
Latest Document Updates:
November 21, 1999 We are now accepting Docbook. We are NOT abadoning
Linuxdoc, however with the increased usage of Docbook in DP projects
(KDE, Postgres, Gnome) we are slowly moving towards Docbook. There is
a preliminary Docbook resource page available here.

Hmm. Tim Bynum, the LDP HowTo coordinator, had expressed interest in
having more Postgres docs available from the LDP, and their web site
mentions us explicitly in the note above. Hopefully we'll get some
resolution of the docs issue sometime soon by moving to DocBook (our
native SGML source format), though I haven't heard back on anything
specific yet :(

- Thomas

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

From bouncefilter Tue Nov 23 22:53:16 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA54834
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 22:52:55 -0500 (EST)
(envelope-from t-ishii@srapc451.sra.co.jp)
Received: from srapc451.sra.co.jp (srapc451 [133.137.44.37])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id MAA17361;
Wed, 24 Nov 1999 12:52:54 +0900 (JST)
Received: from srapc451.sra.co.jp (localhost [127.0.0.1]) by
srapc451.sra.co.jp (8.8.8/3.5Wpl7) with ESMTP id MAA20461;
Wed, 24 Nov 1999 12:52:53 +0900 (JST)
Message-Id: <199911240352.MAA20461@srapc451.sra.co.jp>
To: wieck@debis.com (Jan Wieck)
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] lztext.c
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Wed, 24 Nov 1999 03:26:21 +0100.
<m11qS8T-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Date: Wed, 24 Nov 1999 12:52:53 +0900
Sender: t-ishii@srapc451.sra.co.jp

Don't spend much efford for comparision and the SUBSTRING()
things right now. I already have an additional, generalized
decompressor in mind, that can be used in the comparision for
example to decompress two values on the fly and stop
comparision at the first difference, which usually happens
early in two random datums.

Ok.

Tell me when you have the multi-byte (and maybe cyrillic?)
stuff committed and I'll take my hands back on the code.

I have committed the changes just now, though cyrillic support is not
included. I vaguely recall the discussion about the usefullness of
the cyrillic support.
--
Tatsuo Ishii

From bouncefilter Tue Nov 23 23:58:18 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 XAA68559
for <pgsql-hackers@postgreSQL.org>;
Tue, 23 Nov 1999 23:57:24 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id NAA03306; Wed, 24 Nov 1999 13:55:48 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "PostgreSQL-development" <pgsql-hackers@postgreSQL.org>
Subject: RE: AW: [HACKERS] Getting OID in psql of recent insert
Date: Wed, 24 Nov 1999 14:00:26 +0900
Message-ID: <000c01bf3638$d24ea0a0$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: <199911231958.OAA11605@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

Good point, but (AFAIK) you could only use it for tables

that you were

sure no other client was updating in parallel. Otherwise

you might be

updating a just-obsoleted tuple. Or is there a solution for that?

Is someone still working on the xid access ?

I think we have the ability to refer to CTID in WHERE now,

but not yet an

access method that actually makes it fast...

Hiroshi supplied a patch to allow it in the executor, and I

applied it.

Bruce,could you apply my attached patch ?
I have to add 3 new files but couldn't do 'cvs add'
the files on my machine.
Am I mistaken ?
I couldn't understand the reason now.

Applied. No idea why the add didn't work there. It worked here.

Thanks a lot.

I don't know CVS well.
Could someone teach me ?

It seems that 'cvs add' on my current machine connects to
postgresql.org.
Is it right ?
Isn't 'cvs add' local ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Nov 24 00:09:18 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA72970
for <pgsql-hackers@postgreSQL.org>;
Wed, 24 Nov 1999 00:08:21 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA21595;
Wed, 24 Nov 1999 00:07:35 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911240507.AAA21595@candle.pha.pa.us>
Subject: Re: AW: [HACKERS] Getting OID in psql of recent insert
In-Reply-To: <000c01bf3638$d24ea0a0$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Nov 24, 1999 02:00:26 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Wed, 24 Nov 1999 00:07:35 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

the files on my machine.
Am I mistaken ?
I couldn't understand the reason now.

Applied. No idea why the add didn't work there. It worked here.

Thanks a lot.

I don't know CVS well.
Could someone teach me ?

It seems that 'cvs add' on my current machine connects to
postgresql.org.
Is it right ?
Isn't 'cvs add' local ?

It is local, but has to register it with the server.

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

From bouncefilter Wed Nov 24 01:09: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 BAA80447
for <pgsql-hackers@postgreSQL.org>;
Wed, 24 Nov 1999 01:08:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA09308;
Wed, 24 Nov 1999 01:07:41 -0500 (EST)
To: Alessio Bragadini <alessio@albourne.com>
cc: PostgreSQL Hacker <pgsql-hackers@postgreSQL.org>,
Adriaan Joubert <a.joubert@albourne.com>
Subject: Re: [HACKERS] A bug or a feature?
In-reply-to: Your message of Tue, 23 Nov 1999 20:03:48 +0200
<383AD704.C464CC26@albourne.com>
Date: Wed, 24 Nov 1999 01:07:40 -0500
Message-ID: <9306.943423660@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Alessio Bragadini <alessio@albourne.com> writes:

We have a table with ~30 columns, named 'people' and we were going to
create a view for all record with 'relationship' equal to 1. The
database complains where using the '*' placeholder:
albourne=> CREATE VIEW employees AS SELECT * FROM people WHERE
relationship = 1;
ERROR: DefineQueryRewrite: rule plan string too big.
but accepts the same 30 columns on the command:

There is a limit on the length of rule plans :-(. Jan has implemented
compression of rule plan strings as a partial workaround for 7.0, and
the final solution will come when we eliminate tuple length limits.

In the meantime, the interesting question is why two apparently
equivalent queries yield rule plans of different lengths. As far as
I can tell, '*' and explicitly listing the fields *do* yield exactly
the same results. My guess is that your query is right at the hairy
edge of the length limit, such that one or two characters more or less
make the difference. The rule plan does include a couple of instances
of the name of the view, so if you used a longer view name in one case
than the other, that could explain why one worked and the other didn't.

If that's not it then I'm baffled...

regards, tom lane

From bouncefilter Wed Nov 24 01:12:18 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA80804
for <pgsql-hackers@hub.org>; Wed, 24 Nov 1999 01:12:02 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id PAA27633
for <pgsql-hackers@hub.org>; Wed, 24 Nov 1999 15:12:00 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id PAA16252
for <pgsql-hackers@hub.org>; Wed, 24 Nov 1999 15:12:00 +0900
To: pgsql-hackers@hub.org
Subject: pid file for postmaster?
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991124151159B.t-ishii@sra.co.jp>
Date: Wed, 24 Nov 1999 15:11:59 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 6

Hi,

It would be nice if postmaster has its own pid file to send signals to
it. I think the pid file could be placed under $PGDATA. Opinions?
--
Tatsuo Ishii

From bouncefilter Wed Nov 24 01:18: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 BAA81442
for <pgsql-hackers@postgreSQL.org>;
Wed, 24 Nov 1999 01:17:57 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA09376;
Wed, 24 Nov 1999 01:16:27 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Cache on pg_statistics
In-reply-to: Your message of Tue, 23 Nov 1999 19:44:02 -0500 (EST)
<199911240044.TAA11932@candle.pha.pa.us>
Date: Wed, 24 Nov 1999 01:16:27 -0500
Message-ID: <9374.943424187@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Tom, let me know what caches you want on pg_statistics, or if you would
prefer to do it yourself, instructions are at the top of syscache.c.

AFAIK the only index we need is one on starelid + staattnum. If you
have the time, please put it in and teach getattstatistics() in
backend/utils/adt/selfuncs.c to use it. That seems to be the only
place that reads pg_statistic.

If you wanted to include staop as a third column, then the index could
be UNIQUE. (We don't actually use staop at the moment, but I think it
should be left in place for possible future use.)

vacuum.c may also need to be taught to fill the index...

regards, tom lane

From bouncefilter Wed Nov 24 01:30:21 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA82705
for <pgsql-hackers@postgresql.org>;
Wed, 24 Nov 1999 01:29:41 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA09435;
Wed, 24 Nov 1999 01:29:02 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: "'PostgreSQL-development'" <pgsql-hackers@postgresql.org>
Subject: Re: AW: [HACKERS] Getting OID in psql of recent insert
In-reply-to: Your message of Wed, 24 Nov 1999 01:56:43 +0100 (CET)
<Pine.LNX.4.20.9911222254330.417-100000@localhost.localdomain>
Date: Wed, 24 Nov 1999 01:29:01 -0500
Message-ID: <9433.943424941@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

Also, looking for possible conflicts here, it seems that there is an
operator ':' for exponentiation, which is of course extremely mnemonic.
This reminds me of the ';' operator for logarithms, which I also use all
the time in mathematical writing. Are those operators actually standard or
just somebody's personal idea?

My guess is that someone back in the Berkeley days put them in as a tour
de force in parser-writing. An impressive show of skill it is, too;
I'm continually astonished that we are not having severe grammar ambiguity
problems from the fact that ';' can be an operator as well as a
statement terminator. ':' is only marginally safer. Yet, by golly,
they parse, and have continued to parse despite extensive later changes
to the pgsql grammar. Whoever that was knew his stuff.

Sooner or later, however, they'll probably break.

I'd not object if we removed these operators and instead provided
functions with the standard names log() and exp() for all the
non-integral numeric types. Comments?

regards, tom lane

From bouncefilter Wed Nov 24 01:35:20 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA83228
for <pgsql-hackers@hub.org>; Wed, 24 Nov 1999 01:34:21 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA09477;
Wed, 24 Nov 1999 01:33:37 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] pid file for postmaster?
In-reply-to: Your message of Wed, 24 Nov 1999 15:11:59 +0900
<19991124151159B.t-ishii@sra.co.jp>
Date: Wed, 24 Nov 1999 01:33:37 -0500
Message-ID: <9475.943425217@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

It would be nice if postmaster has its own pid file to send signals to
it. I think the pid file could be placed under $PGDATA. Opinions?

Yes, that's been discussed before, and I think it's even got an entry
on the TODO list. If you've got time to tackle it now, great!

$PGDATA seems like the right place to put the file, since we can only
have one active postmaster at a time in a database directory.

I assume you'll also create a script that sends SIGTERM or other
requested signal to the postmaster, using this file?

regards, tom lane

From bouncefilter Wed Nov 24 01:39:21 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA83723
for <pgsql-hackers@hub.org>; Wed, 24 Nov 1999 01:38:33 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id PAA29642;
Wed, 24 Nov 1999 15:38:31 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id PAA16729;
Wed, 24 Nov 1999 15:38:31 +0900
To: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] pid file for postmaster?
In-Reply-To: Your message of "Wed, 24 Nov 1999 01:33:37 -0500"
<9475.943425217@sss.pgh.pa.us>
References: <9475.943425217@sss.pgh.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991124153831T.t-ishii@sra.co.jp>
Date: Wed, 24 Nov 1999 15:38:31 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 19

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

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

It would be nice if postmaster has its own pid file to send signals to
it. I think the pid file could be placed under $PGDATA. Opinions?

Yes, that's been discussed before, and I think it's even got an entry
on the TODO list. If you've got time to tackle it now, great!

$PGDATA seems like the right place to put the file, since we can only
have one active postmaster at a time in a database directory.

Right.

I assume you'll also create a script that sends SIGTERM or other
requested signal to the postmaster, using this file?

Of course:-) I'm thinking about to make an apachectl-like script.
--
Tatsuo Ishii

From bouncefilter Wed Nov 24 01:50: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 BAA85551
for <pgsql-hackers@hub.org>; Wed, 24 Nov 1999 01:50:17 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA09536;
Wed, 24 Nov 1999 01:49:38 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] pid file for postmaster?
In-reply-to: Your message of Wed, 24 Nov 1999 15:38:31 +0900
<19991124153831T.t-ishii@sra.co.jp>
Date: Wed, 24 Nov 1999 01:49:38 -0500
Message-ID: <9534.943426178@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

I assume you'll also create a script that sends SIGTERM or other
requested signal to the postmaster, using this file?

Of course:-) I'm thinking about to make an apachectl-like script.

If you think Apache has a good user interface for a signal-sending
script, then by all means steal their design ;-). If not that, we
should steal someone else's. No reason to reinvent this wheel,
nor to make sysadmins learn yet another variant on the theme.

regards, tom lane

From bouncefilter Wed Nov 24 02:11:21 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 CAA88246
for <pgsql-hackers@postgreSQL.org>;
Wed, 24 Nov 1999 02:10:26 -0500 (EST) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id KAA15319;
Wed, 24 Nov 1999 10:09:05 +0300 (MSK)
Date: Wed, 24 Nov 1999 10:09:04 +0300 (MSK)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: Jan Wieck <wieck@debis.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] lztext.c
In-Reply-To: <199911240352.MAA20461@srapc451.sra.co.jp>
Message-ID: <Pine.GSO.3.96.SK.991124100732.3910d-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 24 Nov 1999, Tatsuo Ishii wrote:

Date: Wed, 24 Nov 1999 12:52:53 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
To: Jan Wieck <wieck@debis.com>
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] lztext.c

Don't spend much efford for comparision and the SUBSTRING()
things right now. I already have an additional, generalized
decompressor in mind, that can be used in the comparision for
example to decompress two values on the fly and stop
comparision at the first difference, which usually happens
early in two random datums.

Ok.

Tell me when you have the multi-byte (and maybe cyrillic?)
stuff committed and I'll take my hands back on the code.

I have committed the changes just now, though cyrillic support is not
included. I vaguely recall the discussion about the usefullness of
the cyrillic support.

If you mean --recode you-re right.

--
Tatsuo Ishii

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

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

From bouncefilter Wed Nov 24 02:32:20 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 CAA90588
for <pgsql-hackers@postgreSQL.org>;
Wed, 24 Nov 1999 02:31:33 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id QAA03401; Wed, 24 Nov 1999 16:31:24 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Zeugswetter Andreas SEV" <ZeugswetterA@wien.spardat.at>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: AW: AW: [HACKERS] Getting OID in psql of recent insert
Date: Wed, 24 Nov 1999 16:36:02 +0900
Message-ID: <001401bf364e$8eff2ca0$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:
<219F68D65015D011A8E000006F8590C603FDC18B@sdexcsrv1.f000.d0188.sd.spardat.at>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

They get the location they ask for, or a failure. Hunting around for
the new tuple seems like a real waste, and if someone vacuums, it is
gone, no?

It is probably worse, since they might even get the wrong row,
but that's the same in Informix and Oracle.

In Informix:

a: selects rowid
b: updates row, row grows, does not fit in page, is relocated
c: inserts rows, pysical location of rowid is reused
a: selects row by rowid, gets differet row --> bummer

In my implementation,scan by old(updated) tupleid fails.
For example,

=> create table t (dt int4);
CREATE
=> insert into t values (1);
INSERT 18601 1
=> select ctid,* from t;
ctid |dt
-----+--
(0,1)| 1
(1 row)

=> select * from t where ctid='(0,1)';
dt
--
1
(1 row)

=> update t set dt=2;
UPDATE 1
=> select * from t where ctid='(0,1)';
dt
--
(0 rows)

In order to get new tids,I provided functions currtid() and currtid2().

=> select currtid2('t','(0,1)');
currtid2
--------
(0,2)
(1 row)

=> select * from t where ctid='(0,2)';
dt
--
2
(1 row)

Of cource,this function is not effective after vacuum.
If you want to detect the change by vacuum,keep oids together with tids.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Wed Nov 24 04:24:21 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 EAA03861
for <pgsql-hackers@postgreSQL.org>;
Wed, 24 Nov 1999 04:24:19 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA218308
for <pgsql-hackers@postgreSQL.org>; Wed, 24 Nov 1999 10:24:17 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <45YXQ735>; Wed, 24 Nov 1999 10:24:17 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC18C@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
Subject: AW: AW: [HACKERS] Getting OID in psql of recent insert (; and : o
perators)
Date: Wed, 24 Nov 1999 10:24:15 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Sooner or later, however, they'll probably break.

Or at least cause substantial headaches.

I'd not object if we removed these operators and instead provided
functions with the standard names log() and exp() for all the
non-integral numeric types. Comments?

Sounds very reasonable, and also improves readability and
portability of the user's sql statements.

Andreas

From bouncefilter Wed Nov 24 11:53:27 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA77327
for <pgsql-hackers@postgreSQL.org>;
Wed, 24 Nov 1999 11:52:55 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
LAA26858;
Wed, 24 Nov 1999 11:52:27 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911241652.LAA26858@candle.pha.pa.us>
Subject: Re: missing Tidscan.h
In-Reply-To: <m11qZ3U-0003kGC@orion.SAPserv.Hamburg.dsh.de> from Jan Wieck at
"Nov 24, 1999 10:49:40 am"
To: Jan Wieck <wieck@debis.com>
Date: Wed, 24 Nov 1999 11:52:27 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi,

you committed a patch from Hiroshi about Tidscan access
yesterday. Now the sources miss the Tidscan.h, so I assume
it wasn't a unified diff or at least patch left it somewhere
else.

Man, I am terrible. Take that keyboard away from me.

File added. I am in the middle of adding pg_statistic index, so initdb
everyone. That change is coming in too, though there are no hooks to
update or use the cache yet.

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

From bouncefilter Wed Nov 24 12:24:43 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA83819;
Wed, 24 Nov 1999 12:24:11 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64634 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sD/wf113063>; Wed, 24 Nov 1999 18:23:55 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11qgDP-0002C2-00; Wed, 24 Nov 1999 18:28:23 +0100
Date: Wed, 24 Nov 1999 18:28:23 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Vince Vielhaber <vev@michvhf.com>, docs@postgresql.org,
Postgres Hackers List <hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [DOCS] RE: file name error (fwd)
In-Reply-To: <383AA4A3.5B4510B9@alumni.caltech.edu>
Message-ID: <Pine.LNX.4.20.9911240229260.352-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 1999-11-23, Thomas Lockhart mentioned:

Was someone going to rewrite the installation procedure? I was looking
at it myself and agree with the thread from a month or two ago that it
is *much* too complicated and verbose. Several steps should be moved
to subsequent sections as reference or backup material (e.g. flex,
regression tests), and the whole thing could be substantially
condensed.

Along the way, I am currently collecting evidence for a
installation/makefile/autoconf/source tree cleanup. The documentation
update should probably be done along with this. When I get some time (not
before the end of this year) I would be willing to work on this, perhaps
together with Vince, as he had some good ideas a while back.

-Peter

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

From bouncefilter Wed Nov 24 12:24:36 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA83832
for <hackers@postgresql.org>; Wed, 24 Nov 1999 12:24:23 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64800 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sD/wy68007>; Wed, 24 Nov 1999 18:24:14 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11qgDu-0002DZ-00
for hackers@postgresql.org; Wed, 24 Nov 1999 18:28:54 +0100
Date: Wed, 24 Nov 1999 18:28:54 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: hackers@postgresql.org
Subject: Development installation fails
Message-ID: <Pine.LNX.4.20.9911241759440.8340-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

For some reason I can never properly install a build from the development
sources. I have always avoided it, but now I must. I don't have the very
latest sources, but it seems I am doing something fundamentally wrong here
because all hell usually breaks loose when I try. So perhaps someone that
does this all the time can give me a few hints here.

I have a 6.5.* installation in /usr/local/pgsql (from /usr/src/pgsql).
/usr/local/pgsql is in the path, /usr/local/pgsql/lib is in ld.config.
(Linux system). The development sources I have in /home/peter/pgsql and I
want to install into /home/peter/postgres-cur. That's the setup.

~/pgsql/src$ ./configure --prefix=/home/peter/postgres-cur
works fine.

~/pgsql/src$ make
bombs out somewhere in backend/optimizer with internal compiler error (gcc
2.8.1) and/or weird make file complaints (GNU make 3.76.1). Try again with
egcs 2.91.66 works.

~/pgsql/src$ make install

~/postgres-cur/bin$ ./initdb --pglib=/home/peter/postgres-cur/lib \
--pgdata=/home/peter/postgres-cur/data

We are initializing the database system with username peter (uid=500).
This user will own all the files and must also own the server process.

Creating Postgres database system directory /home/peter/postgres-cur/data

Creating Postgres database system directory
/home/peter/postgres-cur/data/base

Creating Postgres database XLOG directory
/home/peter/postgres-cur/data/pg_xlog

Creating template database in /home/peter/postgres-cur/data/base/template1
-boot: invalid option -- x
Usage: postgres -boot [-d] [-C] [-F] [-O] [-Q] [-P portno] [dbName]
d: debug mode
C: disable version checking
F: turn off fsync
O: set BootstrapProcessing mode
P portno: specify port number
initdb: could not create template database

Okay, that's the first problem. So I removed that -x flag out of initdb
(look for shell variable FIRSTRUN). Next try:

~/postgres-cur/bin$ ./initdb --pglib=/home/peter/postgres-cur/lib \
--pgdata=/home/peter/postgres-cur/data

We are initializing the database system with username peter (uid=500).
This user will own all the files and must also own the server process.

Creating template database in /home/peter/postgres-cur/data/base/template1
syntax error 2370 : parse error
Creating global classes in /home/peter/postgres-cur/data/base

Adding template1 database to pg_database...

Vacuuming template1
Creating public pg_user view
Creating view pg_rules
Creating view pg_views
Creating view pg_tables
Creating view pg_indexes

Despite the error things seem to have been completed fine.

~/postgres-cur/bin$ ./postmaster -p 6543 -D /home/peter/postgres-cur/data/
Database system in directory /home/peter/postgres-cur/data/ is not
compatible with this version of Postgres, or we are unable to read the
PG_VERSION file. Explanation from ValidatePgVersion: Version number in
file '/home/peter/postgres-cur/data//PG_VERSION' should be 7.0, not 6.5.

No data directory -- can't proceed.

Okay, so I change all the 6.5's to 7.0's by hand and try again.

~/postgres-cur/bin$ ./postmaster -p 6543 -D /home/peter/postgres-cur/data
DEBUG: Data Base System is starting up at Wed Nov 24 17:58:40 1999
FATAL 2: Open(cntlfile) failed: 2
FATAL 2: Open(cntlfile) failed: 2
Startup failed - abort

At this point I thought I'd better stop messing around and ask what's
going on here.

Probably the paths of my "production" installation and the development
installation interfere with each other, but there must be a way I can do
this in a simple fashion and without affecting my running database.

Thanks,
Peter

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

From bouncefilter Wed Nov 24 13:30:38 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id NAA07873
for <docs@postgreSQL.org>; Wed, 24 Nov 1999 13:30:16 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 26741 invoked by uid 1001); 24 Nov 1999 18:30:18 -0000
Date: Wed, 24 Nov 1999 13:30:18 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: Peter Eisentraut <peter_e@gmx.net>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>, docs@postgreSQL.org,
Postgres Hackers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [DOCS] RE: file name error (fwd)
In-Reply-To: <Pine.LNX.4.20.9911240229260.352-100000@localhost.localdomain>
Message-ID: <Pine.BSF.4.05.9911241327570.26733-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 24 Nov 1999, Peter Eisentraut wrote:

On 1999-11-23, Thomas Lockhart mentioned:

Was someone going to rewrite the installation procedure? I was looking
at it myself and agree with the thread from a month or two ago that it
is *much* too complicated and verbose. Several steps should be moved
to subsequent sections as reference or backup material (e.g. flex,
regression tests), and the whole thing could be substantially
condensed.

Along the way, I am currently collecting evidence for a
installation/makefile/autoconf/source tree cleanup. The documentation
update should probably be done along with this. When I get some time (not
before the end of this year) I would be willing to work on this, perhaps
together with Vince, as he had some good ideas a while back.

I looked around on three different machines for the document I was working
on when I finally realized why it's nowhere to be found. I deleted it
'cuze it became clear that configure needed to be changed and there's a
good chance it's beyond me to do it. I was thinking along the lines of
an additional --with for the postgres user and using that for install.

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

From bouncefilter Wed Nov 24 14:40:37 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA17432
for <hackers@postgreSQL.org>; Wed, 24 Nov 1999 14:39:44 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id OAA10963;
Wed, 24 Nov 1999 14:39:08 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Development installation fails
In-reply-to: Your message of Wed, 24 Nov 1999 18:28:54 +0100 (CET)
<Pine.LNX.4.20.9911241759440.8340-100000@localhost.localdomain>
Date: Wed, 24 Nov 1999 14:39:08 -0500
Message-ID: <10961.943472348@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

For some reason I can never properly install a build from the development

It looks to me like you have a conflict against a production
installation on the same machine. It is *not sufficient* to install
into an alternate directory; you must also select an alternate port
number. See the new 'run_check.sh' regress test driver for a complete
example.

Jan reported recently that there were places that didn't pay attention
to the -D switch, which is a bug that will likely bite you if you are
trying to install into a directory other than the configured-in one.
However that doesn't seem to be the issue here.

Personally I build test versions with

./configure --with-pgport=5440 --prefix=/users/postgres/testversion

(adapt port and prefix to taste, of course) and then I don't have to
worry about remembering to do the install specially.

I dunno about the other problems you are seeing. I run a full build
and install from scratch at least a couple times a week, just to be
sure that current sources are not broken. They weren't as of ... hmm
... 20:55 EST 22-Nov was my last CVS pull. Anyway:

~/pgsql/src$ make
bombs out somewhere in backend/optimizer with internal compiler error (gcc
2.8.1) and/or weird make file complaints (GNU make 3.76.1). Try again with
egcs 2.91.66 works.

Hmm. I have been using make 3.76.1 right along with no problems. What
were the make complaints again? Also, I'm still running gcc 2.7.2.2,
so I'm a bit surprised to hear that 2.8.1 crashes. (Or maybe not ...
there's a reason I never updated to 2.8.* ...)

~/postgres-cur/bin$ ./initdb --pglib=/home/peter/postgres-cur/lib \
--pgdata=/home/peter/postgres-cur/data

You may need to have env variables PGDATA and PGLIB set during initdb
(at least, the install docs recommended that last I looked) and you
definitely need to have /home/peter/postgres-cur/bin in your PATH.

It looks to me like initdb.sh may need to do "export PGDATA PGLIB" to
make sure that whatever values it gets from command line switches are
passed down to the programs it invokes... the PATH is just something
you have to get right...

Creating template database in /home/peter/postgres-cur/data/base/template1
-boot: invalid option -- x

I think you were already invoking the wrong version of postgres here;
the current sources do support -x (although bootstrap.c's usage()
neglects to list it). If it wasn't listed in your PATH ahead of the
6.5 version, that's your problem right there.

regards, tom lane

From bouncefilter Wed Nov 24 18:38:40 1999
Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net
[194.217.242.38]) by hub.org (8.9.3/8.9.3) with ESMTP id SAA46380
for <hackers@postgresql.org>; Wed, 24 Nov 1999 18:37:49 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1)
id 11qlyt-000MOL-0A
for hackers@postgreSQL.org; Wed, 24 Nov 1999 23:37:47 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id XAA23570; Wed, 24 Nov 1999 23:37:43 GMT
Message-Id: <199911242337.XAA23570@mtcc.demon.co.uk>
Date: Wed, 24 Nov 1999 23:37:43 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: run_check problem
To: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: sPKzFnuCla/1YWJosQ7/eg==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

Hi all,

I'm getting an error in run_check.sh on Solaris.

MULTIBYTE=;export MULTIBYTE; \
/bin/sh ./run_check.sh solaris_sparc
awk: syntax error near line 1
awk: illegal statement near line 1
awk: syntax error near line 2
awk: illegal statement near line 2
=============== Create ./tmp_check directory ================
.
.

This is due to 2 problems.

1) The awk script is broken over 2 lines.
2) Solaris's awk does not seem to understand REs in split(). (nawk's OK)

1 is easy to fix, 2 is tricky - to remain portable.

Keith.

From bouncefilter Wed Nov 24 19:19:40 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 TAA50756
for <pgsql-hackers@postgreSQL.org>;
Wed, 24 Nov 1999 19:18:56 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11qmTx-0003kGC; Thu, 25 Nov 99 01:09 MET
Message-Id: <m11qmTx-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: lztext and parser
To: pgsql-hackers@postgreSQL.org (PostgreSQL HACKERS)
Date: Thu, 25 Nov 1999 01:09:53 +0100 (MET)
Reply-To: wieck@debis.com (Jan Wieck)
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hi,

I'm hacking in the operator functions for the lztext type and
have a little question.

With the generic per-byte decompressor I added, it would be
very easy to produce functions like

bool lztext_text_eq(lztext, text)
bool text_lztext_eq(text, lztext)

too. Comparision between lztext and text does already work
because there are lztext->text and vice versa functions
available and the parser automatically typecasts.

So would it be a win or a dead end street to provide those
functions? Does it look for a direct comparision function
allways first? Then it would be, because it would never
choose to compress the text item and then compare two
lztext's (what would be terrible).

Jan

--

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

From bouncefilter Wed Nov 24 19:25:40 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA51526
for <pgsql-hackers@postgreSQL.org>;
Wed, 24 Nov 1999 19:24:45 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA29865;
Wed, 24 Nov 1999 19:21:07 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911250021.TAA29865@candle.pha.pa.us>
Subject: Re: [HACKERS] Cache on pg_statistics
In-Reply-To: <9374.943424187@sss.pgh.pa.us> from Tom Lane at "Nov 24,
1999 01:16:27 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Wed, 24 Nov 1999 19:21:07 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Tom, let me know what caches you want on pg_statistics, or if you would
prefer to do it yourself, instructions are at the top of syscache.c.

AFAIK the only index we need is one on starelid + staattnum. If you
have the time, please put it in and teach getattstatistics() in
backend/utils/adt/selfuncs.c to use it. That seems to be the only
place that reads pg_statistic.

If you wanted to include staop as a third column, then the index could
be UNIQUE. (We don't actually use staop at the moment, but I think it
should be left in place for possible future use.)

vacuum.c may also need to be taught to fill the index...

Done. Let me know how it works. I had to add selop param to the
function getattstatistics() because I needed it to find the cache entry
because that field is in the cache.

Not sure how to test if it is working.

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

From bouncefilter Wed Nov 24 20:56:41 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 UAA63409
for <hackers@postgreSQL.org>; Wed, 24 Nov 1999 20:56:39 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11qo05-0003kGC; Thu, 25 Nov 99 02:47 MET
Message-Id: <m11qo05-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] run_check problem
To: emkxp01@mtcc.demon.co.uk
Date: Thu, 25 Nov 1999 02:47:09 +0100 (MET)
Cc: hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199911242337.XAA23570@mtcc.demon.co.uk> from "Keith Parks" at
Nov 24, 99 11:37:43 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Hi all,

I'm getting an error in run_check.sh on Solaris.

MULTIBYTE=;export MULTIBYTE; \
/bin/sh ./run_check.sh solaris_sparc
awk: syntax error near line 1
.
.

1) The awk script is broken over 2 lines.
2) Solaris's awk does not seem to understand REs in split(). (nawk's OK)

Argh - now I remember why we tried to avoid awk as much as
possible. Why do the sun guy's ship such a crippled version
for a good old UNIX V7 tool? I rememver that MINIX already
had a better one! DAMNED BLOODY MOTHERF...

And I discovered another problem with it too. The path
replacements in various scripts (especially those loading
shared objects at runtime) need to use the ones from the temp
installation. But that's surely hackable.

Jan

--

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

From bouncefilter Wed Nov 24 21:33: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 VAA67689
for <pgsql-hackers@postgreSQL.org>;
Wed, 24 Nov 1999 21:32:55 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11qoZc-0003kGC; Thu, 25 Nov 99 03:23 MET
Message-Id: <m11qoZc-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] lztext.c
To: t-ishii@sra.co.jp
Date: Thu, 25 Nov 1999 03:23:52 +0100 (MET)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <199911240352.MAA20461@srapc451.sra.co.jp> from "Tatsuo Ishii" at
Nov 24, 99 12:52:53 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Tatsuo Ishii wrote:

Don't spend much efford for comparision and the SUBSTRING()
things right now. I already have an additional, generalized
decompressor in mind, that can be used in the comparision for
example to decompress two values on the fly and stop
comparision at the first difference, which usually happens
early in two random datums.

Ok.

Tell me when you have the multi-byte (and maybe cyrillic?)
stuff committed and I'll take my hands back on the code.

I have committed the changes just now, though cyrillic support is not
included. I vaguely recall the discussion about the usefullness of
the cyrillic support.

I added the comparision functions, operators and the default
nbtree operator class for indexing.

For the SUBSTR() and STRPOS(), I just checked the current
setup and it automatically casts an lztext argument in these
functions to text. I assume lztext can now be used in every
place where text is allowed. Is it really worth to blow up
the catalogs with rarely used functions that only gain some
saved decompressed portion?

Remember, the algorithm is optimized for decompression speed.
It might save some time to do this for a comparision function
used inside of index scans or btree operations, where it's
likely to hit a difference early. But for something like
STRPOS(), using the default cast and changing the STRPOS()
match search itself into a KMP algorithm (instead of walking
through the text and comparing each position against the
pattern using strncmp) would outperform it in any case. With
the byte by byte strncmp() method, we definitely implemented
the slowest and best readable possibility.

I think we should better spend our time in adding a lzbpchar
type. Or work on compressed tables and tuple split to blow
away the size limits at all.

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 Nov 25 00:43: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 AAA93853
for <hackers@postgreSQL.org>; Thu, 25 Nov 1999 00:43:40 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA12131;
Thu, 25 Nov 1999 00:43:01 -0500 (EST)
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] run_check problem
In-reply-to: Your message of Wed, 24 Nov 1999 23:37:43 +0000 (GMT)
<199911242337.XAA23570@mtcc.demon.co.uk>
Date: Thu, 25 Nov 1999 00:43:01 -0500
Message-ID: <12129.943508581@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Keith Parks <emkxp01@mtcc.demon.co.uk> writes:

This is due to 2 problems.
1) The awk script is broken over 2 lines.
2) Solaris's awk does not seem to understand REs in split(). (nawk's OK)

I don't think so --- the exact same split() construct is there in the
old regress.sh test driver, same as it ever was. I can believe the line
break is a problem, but if there's another problem then you need to
keep digging.

Comparing the two scripts, I wonder if Jan broke it by adding '/bin/sh'
to the invocation of config.guess. Doesn't seem very likely, but...

regards, tom lane

From bouncefilter Thu Nov 25 01:05:44 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 BAA96307
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 01:05:12 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id PAA03912; Thu, 25 Nov 1999 15:04:54 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Concurrent VACUUM: first results
Date: Thu, 25 Nov 1999 15:09:33 +0900
Message-ID: <000501bf370b$a47badc0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <5068.943339265@sss.pgh.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

Well, I diked out the code in vacuum.c that creates/deletes the pg_vlock
lockfile, and tried it out. Turns out it's not quite such a no-brainer
as I'd hoped. Several problems emerged:

1. You can run concurrent "VACUUM" this way, but concurrent "VACUUM
ANALYZE" blows up. The problem seems to be that "VACUUM ANALYZE"'s
first move is to delete all available rows in pg_statistic. That
generates a conflict against other vacuums that might be inserting new
rows in pg_statistic. The newly started VACUUM will almost always hang
up on a not-yet-committed pg_statistic row, waiting to see whether that
row commits so that it can delete it. Even more interesting, the older
VACUUM generally hangs up shortly after that; I'm not perfectly clear on
what *it's* waiting on, but it's obviously a mutual deadlock situation.
The two VACUUMs don't fail with a nice "deadlock detected" message,
either ... it's more like a 60-second spinlock timeout, followed by
abort() coredumps in both backends, followed by the postmaster killing
every other backend in sight. That's clearly not acceptable behavior
for production databases.

The following stuff in vc_vacuum() may be a cause.

/* get list of relations */
vrl = vc_getrels(VacRelP);

if (analyze && VacRelP == NULL && vrl != NULL)
vc_delhilowstats(InvalidOid, 0, NULL);

/* vacuum each heap relation */

CommitTransactionCommand() is executed at the end of vc_getrels()
and vc_delhilowstats() is executed without StartTransactionCommand().

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Thu Nov 25 01:18: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 BAA97487
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 01:17:57 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA12360;
Thu, 25 Nov 1999 01:17:22 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Concurrent VACUUM: first results
In-reply-to: Your message of Thu, 25 Nov 1999 15:09:33 +0900
<000501bf370b$a47badc0$2801007e@cadzone.tpf.co.jp>
Date: Thu, 25 Nov 1999 01:17:21 -0500
Message-ID: <12358.943510641@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

CommitTransactionCommand() is executed at the end of vc_getrels()
and vc_delhilowstats() is executed without StartTransactionCommand().

Oooh, good eye! I wonder how long that bug's been there?

I'm still inclined to remove that call to vc_delhilowstats, because it
seems like a global delete of statistics can't help but be a problem.
But if we keep it, you're dead right: it has to be inside a transaction.

regards, tom lane

From bouncefilter Thu Nov 25 14:13:54 1999
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA97672
for <pgsql-hackers@hub.org>; Thu, 25 Nov 1999 14:13:08 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3DD3.dip0.t-ipconnect.de
(root@p3E9D3DD3.dip0.t-ipconnect.de [62.157.61.211])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id UAA67902
for <pgsql-hackers@hub.org>; Thu, 25 Nov 1999 20:05:38 +0100 (CET)
(envelope-from michael@fam-meskes.de)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.0/Debian/GNU) id IAA00755
for pgsql-hackers@hub.org; Thu, 25 Nov 1999 08:20:33 +0100
Date: Thu, 25 Nov 1999 08:20:33 +0100
From: Michael Meskes <meskes@postgresql.org>
To: pgsql-hackers@hub.org
Subject: Re: [HACKERS] pid file for postmaster?
Message-ID: <19991125082033.D721@fam-meskes.de>
Mail-Followup-To: pgsql-hackers@hub.org
References: <19991124151159B.t-ishii@sra.co.jp> <9475.943425217@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <9475.943425217@sss.pgh.pa.us>;
from tgl@sss.pgh.pa.us on Wed, Nov 24, 1999 at 01:33:37AM -0500

On Wed, Nov 24, 1999 at 01:33:37AM -0500, Tom Lane wrote:

it. I think the pid file could be placed under $PGDATA. Opinions?

...
$PGDATA seems like the right place to put the file, since we can only
have one active postmaster at a time in a database directory.

Ehem, I think the correct place would be /var/run. At least that's what the
filesystem standard says IIRC.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Thu Nov 25 03:27:46 1999
Received: from wilk.lupus.pl (root@wilk.lupus.pl [195.116.206.178])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA13495
for <pgsql-hackers@postgresql.org>;
Thu, 25 Nov 1999 03:27:08 -0500 (EST)
(envelope-from grzegorz_przezdziecki@lupus.waw.pl)
Received: from lupus.waw.pl ([195.116.206.134])
by wilk.lupus.pl with ESMTP id KAA14862
for <pgsql-hackers@postgresql.org>; Thu, 25 Nov 1999 10:12:15 +0100
Message-ID: <383CF2CA.203FD7E@lupus.waw.pl>
Date: Thu, 25 Nov 1999 09:26:50 +0100
From: Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?=
<grzegorz_przezdziecki@lupus.waw.pl>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Vacuum
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit

Welcom.

I have that message every time when I do vacuum;

vacuum;
NOTICE: Index tb_klienci_id_klienci_key: NUMBER OF INDEX' TUPLES (8776)
IS NOT
THE SAME AS HEAP' (8774)
NOTICE: Index tb_klienci_id_klienci_key: NUMBER OF INDEX' TUPLES (8776)
IS NOT
THE SAME AS HEAP' (8774)
VACUUM

I dont know it is very bad message if that,
I have a problem could you help me.

Sorry for may english

From bouncefilter Thu Nov 25 07:40:49 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id HAA43566
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 07:40:43 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id NAA22892;
Thu, 25 Nov 1999 13:27:23 +0100
Date: Thu, 25 Nov 1999 13:27:22 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: Jan Wieck <wieck@debis.com>
cc: PostgreSQL HACKERS <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] lztext and parser
In-Reply-To: <m11qmTx-0003kGC@orion.SAPserv.Hamburg.dsh.de>
Message-ID: <Pine.LNX.3.96.991125122326.16693B-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 25 Nov 1999, Jan Wieck wrote:

Hi,

I'm hacking in the operator functions for the lztext type and
have a little question.

Hi,

I see your the lztext/pg_compress in CVS and it is *very* nice,
and I have a little comment.

With the generic per-byte decompressor I added, it would be
very easy to produce functions like

It's very good if compression routines support data stream. Suppose
you add the pre-byte compressor?

Reasoning: What is fastly - (1) a standard data I/O reading or
(2) a compressed data I/O reading and decompress it
(fast CPU vs. slowly I/O)?

IMHO if (2) is fastly is prabably good for something
data use second way. But I don't know where use this
way in PgSQL :-)

too. Comparision between lztext and text does already work
because there are lztext->text and vice versa functions
available and the parser automatically typecasts.

So would it be a win or a dead end street to provide those
functions? Does it look for a direct comparision function
allways first? Then it would be, because it would never
choose to compress the text item and then compare two
lztext's (what would be terrible).

In the lztext_eq(lztext *lz1, lztext *lz2) you use lztext_cmp().
I'm not sure if it is good, because you must decompress fistly, but
you don't need information about '<' or '>', you need '=' only. Why
you not use memcmp() (or other method) for this, and comparate this
without decompression? Two equal string is equal in a compressed form,
or not?

IMHO in some routines (datetime) in PgSQL I saw internal cache, what
add this to the lztext_cmp(), and not decompress all in each time?

All in this letter is comments and suggestions, you can always remove
this letter to /dev/null :-)

Karel

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

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

From bouncefilter Thu Nov 25 07:55:49 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 HAA45488
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 07:55:02 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11qyHW-0003kGC; Thu, 25 Nov 99 13:45 MET
Message-Id: <m11qyHW-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] lztext and parser
To: zakkr@zf.jcu.cz (Karel Zak - Zakkr)
Date: Thu, 25 Nov 1999 13:45:50 +0100 (MET)
Cc: wieck@debis.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.LNX.3.96.991125122326.16693B-100000@ara.zf.jcu.cz> from
"Karel Zak - Zakkr" at Nov 25, 99 01:27:22 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Karel wrote:

In the lztext_eq(lztext *lz1, lztext *lz2) you use lztext_cmp().
I'm not sure if it is good, because you must decompress fistly, but
you don't need information about '<' or '>', you need '=' only. Why
you not use memcmp() (or other method) for this, and comparate this
without decompression? Two equal string is equal in a compressed form,
or not?

For now, yes. But the current lztext implementation is only a
starting poing (still). The final version might have some
runtime customizable parameters for the compression algorithm
(good match size and minimum compression rate). Then, if some
data is stored and the parameters change after, this wouldn't
be true any more.

All in this letter is comments and suggestions, you can always remove
this letter to /dev/null :-)

Would never do so. All suggestions are welcome and might
trigger another idea in someone elses head.

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 Nov 25 08:09:49 1999
Received: from Radha.DoCS.UU.SE (root@Radha.DoCS.UU.SE [130.238.9.99])
by hub.org (8.9.3/8.9.3) with SMTP id IAA47941
for <hackers@postgreSQL.org>; Thu, 25 Nov 1999 08:09:02 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from Panter.DoCS.UU.SE (e99re41@Panter.DoCS.UU.SE [130.238.9.114])
by Radha.DoCS.UU.SE (8.6.12/8.6.12) with ESMTP id OAA24313;
Thu, 25 Nov 1999 14:08:47 +0100
Received: from localhost (e99re41@localhost) by Panter.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id OAA16509;
Thu, 25 Nov 1999 14:08:43 +0100
X-Authentication-Warning: Panter.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Thu, 25 Nov 1999 14:08:41 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: hackers@postgreSQL.org
Subject: Re: [PATCHES] ':' and ';' operators
In-Reply-To: <10921.943470629@sss.pgh.pa.us>
Message-ID: <Pine.GSO.4.02A.9911251323160.16412-100000@Panter.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 24 Nov 1999, Tom Lane wrote:

Peter Eisentraut <peter_e@gmx.net> writes:

This patch removes the ';' (logarithm) and ':' (exponentiation) operators,
as was generally agreed upon.

This is a tad premature IMHO. In the first place, we haven't got the
replacement functions --- at least not with user-friendly names.
In the second place, I think we oughta deprecate these things for a
release or two before we actually remove 'em.

Deprecation is not going to work in this case because those two operators
interfere with their blessed SQL meaning. And now is the time to remove
them. The reason I wanted them removed now is that it is a pain to account
for them, or even disambiguate them, in psql. I guess for now I will no
longer bother with them.

At the risk of taking on more work and/or provoking a holy war, I think
the mathematical operators and function names need some cleaning up in
general. From the previous conversation on this topic I gathered that a
lot of these things are from PostQUEL times. Also, there is some confusion
between float and numeric operators and functions and sometimes they only
work on one, etc.

I don't have the SQL standards around here, but they should be the
reference, so if someone could fill me in. Barring anything that's in
there, I think that there should be a standard set of functions, such as
this:
exp()
log()
pow()
sin(), cos(), ...
abs()
sgn()
factorial()
sqrt()
surd()
floor()
ceil()
trunc()
round()
as well as anything else that's easily thrown in because it's already in
math.h.

All of these functions should be overloaded for float4, float8, and
numeric, as well as int* where appropriate. Some might argue that things
such as sin() or exp() do not make sense for numeric and you should cast
it to float. I'm not sure myself.

Operators should only be assigned if they are in the standard and/or they
make sense to a math person. To me (being a math person), this would
particularly disqualify these operators:
!! -- factorial left operator
% -- truncation left operator (as opposed to % modulo)
: -- exponentiation
; -- logarithm
@ -- absolute value

(Tom speculated that someone might have had some fun writing the parser
and hence threw in these things.)

Rationale:
* Compatibility: break it now or be stuck with it forever
* If anyone actually used the above operators in those meanings, I will
personally congratulate them.
* Someone will have to do it eventually.

This is not something I could do tomorrow anyway, so we can have an
extended discussion. I'm looking forward to it ...

BTW: a patch that removes user-visible features and breaks regress
tests is incomplete without doc and test updates...

When will I ever learn ...
Sorry.

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

From bouncefilter Thu Nov 25 08:20:49 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id IAA49575
for <pgsql-hackers@hub.org>; Thu, 25 Nov 1999 08:20:29 -0500 (EST)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id IAA04039;
Thu, 25 Nov 1999 08:20:16 -0500 (EST)
Message-ID: <383D3771.E0282D5B@southeast.net>
Date: Thu, 25 Nov 1999 08:19:45 -0500
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: tgl@sss.pgh.pa.us, pgsql-hackers@hub.org
Subject: Re: [HACKERS] pid file for postmaster?
References: <9475.943425217@sss.pgh.pa.us> <19991124153831T.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Red Hat ALREADY creates a file "postmaster.pid" in the /var/lock directory.
I don't know how far the /var/lock convention goes across different platforms,
but I recommend using IT or its equivalent, I still have scars from my OS/2
days where every product put its goodies in a different place and you had to
guess where, how, and in what format.

Regards,
Tim Holloway

Tatsuo Ishii wrote:

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

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

It would be nice if postmaster has its own pid file to send signals to
it. I think the pid file could be placed under $PGDATA. Opinions?

Yes, that's been discussed before, and I think it's even got an entry
on the TODO list. If you've got time to tackle it now, great!

$PGDATA seems like the right place to put the file, since we can only
have one active postmaster at a time in a database directory.

Right.

I assume you'll also create a script that sends SIGTERM or other
requested signal to the postmaster, using this file?

Of course:-) I'm thinking about to make an apachectl-like script.
--
Tatsuo Ishii

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

From bouncefilter Thu Nov 25 08:56:50 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA54059
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 08:56:33 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA26900
for <pgsql-hackers@postgreSQL.org>; Thu, 25 Nov 1999 14:43:21 +0100
Date: Thu, 25 Nov 1999 14:43:20 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: PgAccess - small bug?
Message-ID: <Pine.LNX.3.96.991125142323.25441A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

in PgAccess's the create table dialog is small bug. If I define a new table
as interits of other table and I not define any column (as 'field' named this
dialog) - PgAccess return ERROR message "Your table has not field!". But
PgSQL allow define table as:

CREATE TABLE xxx () INHERITS(yyy);

...all colunms is from 'yyy'.

NOTE: Why a attribute (column) is in the PgAccsess named 'field'? It is
abnormal in SQL speech...

Karel

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

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

From bouncefilter Thu Nov 25 10:18:51 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA73204
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 10:18:28 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA12991;
Thu, 25 Nov 1999 10:17:16 -0500 (EST)
To: Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?=
<grzegorz_przezdziecki@lupus.waw.pl>
cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Vacuum
In-reply-to: Your message of Thu, 25 Nov 1999 09:26:50 +0100
<383CF2CA.203FD7E@lupus.waw.pl>
Date: Thu, 25 Nov 1999 10:17:16 -0500
Message-ID: <12989.943543036@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?= <grzegorz_przezdziecki@lupus.waw.pl> writes:

vacuum;
NOTICE: Index tb_klienci_id_klienci_key: NUMBER OF INDEX' TUPLES (8776)
IS NOT THE SAME AS HEAP' (8774)

There are some bugs here that we are looking into fixing for 7.0.
In the meantime, you should be able to get rid of the message by
dropping and recreating that index.

regards, tom lane

From bouncefilter Thu Nov 25 10:48:51 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA76606
for <hackers@postgreSQL.org>; Thu, 25 Nov 1999 10:48:01 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA13146;
Thu, 25 Nov 1999 10:47:21 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: [PATCHES] ':' and ';' operators
In-reply-to: Your message of Thu, 25 Nov 1999 14:08:41 +0100 (MET)
<Pine.GSO.4.02A.9911251323160.16412-100000@Panter.DoCS.UU.SE>
Date: Thu, 25 Nov 1999 10:47:20 -0500
Message-ID: <13144.943544840@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <e99re41@DoCS.UU.SE> writes:

This patch removes the ';' (logarithm) and ':' (exponentiation) operators,
as was generally agreed upon.

This is a tad premature IMHO. In the first place, we haven't got the
replacement functions --- at least not with user-friendly names.
In the second place, I think we oughta deprecate these things for a
release or two before we actually remove 'em.

Deprecation is not going to work in this case because those two operators
interfere with their blessed SQL meaning. And now is the time to remove
them. The reason I wanted them removed now is that it is a pain to account
for them, or even disambiguate them, in psql.

It's always been true (or at least been true for a long time) that ';'
used as an operator has to appear inside parens, like "SELECT (;2)",
to keep psql from thinking that it's a statement terminator. Can't you
maintain that behavior?

':' is a little trickier --- if you want to use it to reference
psql-provided variables, then there's probably no way you can support it
as an SQL operator too. Of course ecpg must have the same problem.

At the risk of taking on more work and/or provoking a holy war, I think
the mathematical operators and function names need some cleaning up in
general. From the previous conversation on this topic I gathered that a
lot of these things are from PostQUEL times. Also, there is some confusion
between float and numeric operators and functions and sometimes they only
work on one, etc.

I think most of the confusion in this area comes from the fact that
while operators have always (?) been overloadable across types, up till
6.5 built-in functions had to have the same names in SQL as in the C
code, and therefore the function names for different data types had to
be different. The only way to overload a function name was to make an
ugly (and slow) SQL function wrapper. So there was a strong notational
advantage to using operator rather than function syntax for anything
that was useful for more than one datatype. That problem's gone now.

I'm not in favor of removing the operators, except maybe for ';' and ':',
but I agree it'd be a fine idea to provide standardized function names
across all the numeric data types, and to make sure that the operators
that are there work on NUMERIC too.

I don't have the SQL standards around here, but they should be the
reference,

SQL doesn't address math functions at all, AFAICS. Given that lack,
the names used in C's <math.h> look OK to me, with the exception that
I'd rather see abs() than fabs().

regards, tom lane

From bouncefilter Thu Nov 25 11:00:52 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA78148
for <pgsql-hackers@hub.org>; Thu, 25 Nov 1999 11:00:20 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA13200;
Thu, 25 Nov 1999 10:59:07 -0500 (EST)
To: Tim Holloway <mtsinc@southeast.net>
cc: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@hub.org
Subject: Re: [HACKERS] pid file for postmaster?
In-reply-to: Your message of Thu, 25 Nov 1999 08:19:45 -0500
<383D3771.E0282D5B@southeast.net>
Date: Thu, 25 Nov 1999 10:59:06 -0500
Message-ID: <13198.943545546@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Tim Holloway <mtsinc@southeast.net> writes:

Red Hat ALREADY creates a file "postmaster.pid" in the /var/lock directory.

If they did it just like that, then they broke the ability to run more
than one postmaster on the same machine. Also, there is the question
of what the permissions are on /var/lock. If they're tight then postgres
can't be an ordinary unprivileged user, which is bad. If they're loose
then anyone can come along and cause trouble by fiddling with the lock
files.

There was considerable discussion of this whole area last year in
pg-hackers (check the thread "flock patch breaks things here" and
related threads starting in late Aug. 1998). We were focusing mostly
on the use of lockfiles to ensure that one didn't accidentally start
two postmasters in the same database dir and/or with the same port
number; but if the lockfiles contain PIDs then of course they can also
serve as a contact point for a signal-sender.

Tatsuo, if you have forgotten that discussion you may want to go back
and re-read it.

regards, tom lane

From bouncefilter Thu Nov 25 11:12:51 1999
Received: from orion.SAPserv.Hamburg.dsh.de (Tpolaris2.sapham.debis.de
[53.2.131.8]) by hub.org (8.9.3/8.9.3) with SMTP id LAA79535
for <hackers@postgreSQL.org>; Thu, 25 Nov 1999 11:12:11 -0500 (EST)
(envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for hackers@postgreSQL.org
id m11r1MH-0003kGC; Thu, 25 Nov 99 17:02 MET
Message-Id: <m11r1MH-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Re: [PATCHES] ':' and ';' operators
To: peter_e@gmx.net
Date: Thu, 25 Nov 1999 17:02:57 +0100 (MET)
Cc: tgl@sss.pgh.pa.us, hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.GSO.4.02A.9911251323160.16412-100000@Panter.DoCS.UU.SE>
from "Peter Eisentraut" at Nov 25, 99 02:08:41 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Peter Eisentraut wrote:

All of these functions should be overloaded for float4, float8, and
numeric, as well as int* where appropriate. Some might argue that things
such as sin() or exp() do not make sense for numeric and you should cast
it to float. I'm not sure myself.

They make sense for numeric, because you can get the sine of
a value with hundreds of SIGNIFICANT digits. Would be damned
slow, but if needed...

NUMERIC has a higher precision than float8. The problem
arising at this point is to ensure that an expression with
mixed attribute types (numeric, floatN and/or integer) must
allways cast anything to numeric if at least one of the
arguments is.

The trigonometric functions are missing for numeric up to
now, but there are Taylor and McLaurin definitions available.

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 Nov 25 11:33:52 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id LAA81787
for <pgsql-hackers@hub.org>; Thu, 25 Nov 1999 11:32:55 -0500 (EST)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id LAA00665;
Thu, 25 Nov 1999 11:32:49 -0500 (EST)
Message-ID: <383D6497.6FD95CE8@southeast.net>
Date: Thu, 25 Nov 1999 11:32:23 -0500
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@hub.org
Subject: Re: [HACKERS] pid file for postmaster?
References: <13198.943545546@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

You are quite correct. They assume that there will be one and only one
postmaster, which may be started or stopped at runlevel switch or
manually via /etc/rc.d/init.d/postmaster stop|start|restart

Similar systems have made PIDfiles like:

/var/run/postgres/5432

Which would get around the single-postmaster limitation and allow you to
make postgres own the PID directory. Whether this has traversal-rights
issues or not, I don't know. Red Hat control starts the postmaster as an
'su' process from root, and they may do the WRITING of the PIDfile from
that account.

Tom Lane wrote:

Tim Holloway <mtsinc@southeast.net> writes:

Red Hat ALREADY creates a file "postmaster.pid" in the /var/lock directory.

If they did it just like that, then they broke the ability to run more
than one postmaster on the same machine. Also, there is the question
of what the permissions are on /var/lock. If they're tight then postgres
can't be an ordinary unprivileged user, which is bad. If they're loose
then anyone can come along and cause trouble by fiddling with the lock
files.

There was considerable discussion of this whole area last year in
pg-hackers (check the thread "flock patch breaks things here" and
related threads starting in late Aug. 1998). We were focusing mostly
on the use of lockfiles to ensure that one didn't accidentally start
two postmasters in the same database dir and/or with the same port
number; but if the lockfiles contain PIDs then of course they can also
serve as a contact point for a signal-sender.

Tatsuo, if you have forgotten that discussion you may want to go back
and re-read it.

regards, tom lane

From bouncefilter Thu Nov 25 17:14:55 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id RAA22170
for <pgsql-hackers@postgresql.org>;
Thu, 25 Nov 1999 17:14:01 -0500 (EST)
(envelope-from mascarm@mascari.com)
From: mascarm@mascari.com
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id RAA29541;
Thu, 25 Nov 1999 17:11:29 -0500
Sender: mascarm@mascari.com
Message-ID: <383D6E0B.863050C8@mascari.com>
Date: Thu, 25 Nov 1999 12:12:44 -0500
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Re: [PATCHES] ':' and ';' operators
References: <13144.943544840@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

I don't have the SQL standards around here, but they should be the
reference,

SQL doesn't address math functions at all, AFAICS. Given that lack,
the names used in C's <math.h> look OK to me, with the exception that
I'd rather see abs() than fabs().

regards, tom lane

For what its worth (I'll probably get brow-beaten for even mentioning this :-) ),
the ODBC 2.0 specification allows clients to test ODBC data sources to determine
if the data source has implemented the following:

ABS(numeric),
ACOS(float),
ASIN(float),
ATAN(float),
ATAN2(float1, float2),
CEILING(numeric),
COS(float),
COT(float),
EXP(float),
FLOOR(numeric),
LOG(float),
MOD(integer1, integer2),
SIGN(numeric),
SIN(float),
SQRT(float),
TAN(float),
PI(),
RAND([integer]),
DEGREES(numeric),
LOG10(float),
POWER(numeric, integer),
RADIANS(numeric),
ROUND(numeric, integer),
TRUNCATE(numeric, integer)

Anways, thats the list for ODBC 2.0 -- I'm not sure what ODBC 3.0 has....

Mike

From bouncefilter Thu Nov 25 14:18:58 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA98210
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 14:18:18 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA10070;
Thu, 25 Nov 1999 13:19:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911251819.NAA10070@candle.pha.pa.us>
Subject: Re: [HACKERS] Concurrent VACUUM: first results
In-Reply-To: <12358.943510641@sss.pgh.pa.us> from Tom Lane at "Nov 25,
1999 01:17:21 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 25 Nov 1999 13:19:37 -0500 (EST)
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

CommitTransactionCommand() is executed at the end of vc_getrels()
and vc_delhilowstats() is executed without StartTransactionCommand().

Oooh, good eye! I wonder how long that bug's been there?

I'm still inclined to remove that call to vc_delhilowstats, because it
seems like a global delete of statistics can't help but be a problem.
But if we keep it, you're dead right: it has to be inside a transaction.

With the new pg_statistic cache, you can efficiently do a heap_insert or
heap_replace dending on whether an entry already exists. In the old
code, that was hard because you had to scan entire table looking for a
match so I just did a delete, and they I knew to do an insert.

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

From bouncefilter Thu Nov 25 14:22:00 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA98848
for <pgsql-hackers@hub.org>; Thu, 25 Nov 1999 14:21:11 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA10783;
Thu, 25 Nov 1999 13:35:14 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911251835.NAA10783@candle.pha.pa.us>
Subject: Re: [HACKERS] pid file for postmaster?
In-Reply-To: <383D3771.E0282D5B@southeast.net> from Tim Holloway at "Nov 25,
1999 08:19:45 am"
To: Tim Holloway <mtsinc@southeast.net>
Date: Thu, 25 Nov 1999 13:35:14 -0500 (EST)
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, tgl@sss.pgh.pa.us, pgsql-hackers@hub.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Red Hat ALREADY creates a file "postmaster.pid" in the /var/lock directory.
I don't know how far the /var/lock convention goes across different platforms,
but I recommend using IT or its equivalent, I still have scars from my OS/2
days where every product put its goodies in a different place and you had to
guess where, how, and in what format.

Problem with that it is going to require root permission to create that
file or directory if it doesn't exist. I think we have to put it in the
pgsql/data directory. Sorry.

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

From bouncefilter Thu Nov 25 14:21:58 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA98820
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 14:21:03 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA10822;
Thu, 25 Nov 1999 13:36:09 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911251836.NAA10822@candle.pha.pa.us>
Subject: Re: [HACKERS] Vacuum
In-Reply-To: <12989.943543036@sss.pgh.pa.us> from Tom Lane at "Nov 25,
1999 10:17:16 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 25 Nov 1999 13:36:09 -0500 (EST)
CC: "Grzegorz [Prze_dziecki]" <grzegorz_przezdziecki@lupus.waw.pl>,
"pgsql-hackers@postgresql.org" <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?= <grzegorz_przezdziecki@lupus.waw.pl> writes:

vacuum;
NOTICE: Index tb_klienci_id_klienci_key: NUMBER OF INDEX' TUPLES (8776)
IS NOT THE SAME AS HEAP' (8774)

There are some bugs here that we are looking into fixing for 7.0.
In the meantime, you should be able to get rid of the message by
dropping and recreating that index.

Yes, and 7.0 message will suggest exactly that.

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

From bouncefilter Thu Nov 25 13:51:53 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA95231
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 13:51:38 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id TAA04815
for <pgsql-hackers@postgreSQL.org>; Thu, 25 Nov 1999 19:38:31 +0100
Date: Thu, 25 Nov 1999 19:38:31 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: pgsql-hackers <pgsql-hackers@postgreSQL.org>
Subject: substring extraction
Message-ID: <Pine.LNX.3.96.991125184601.3411A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

I need in the SELECT query extract substring 'cccc' from string
'aaa.bbbbb.cccc.dd.eee' (extract third field from string if
delimiter is '.').

It is easy if I know where is begin/end of 'cccc' and I can
use the substring() function:

select substring('aaa.bbbbb.cccc.dd.eee' from 11 for 4);
substr
------
cccc

But how extract it if I don't know where is position of the second
and third '.'?

Yes, I know the function position() or textpos(), but this return first
a position of the substring...

For this exist nice UN*X command "cut -f3 -d." , but how make it in
SQL?

I ask about it, because I write for me this as new function in C, but
I'm not sure if not exist other (better) way for it.

Karel

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

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

From bouncefilter Thu Nov 25 14:58:54 1999
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA06049
for <pgsql-hackers@postgresql.org>;
Thu, 25 Nov 1999 14:58:28 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3DEF.dip0.t-ipconnect.de
(root@p3E9D3DEF.dip0.t-ipconnect.de [62.157.61.239])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id UAA71662
for <pgsql-hackers@postgresql.org>;
Thu, 25 Nov 1999 20:51:52 +0100 (CET)
(envelope-from michael@fam-meskes.de)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id UAA01078
for pgsql-hackers@postgresql.org; Thu, 25 Nov 1999 20:25:21 +0100
Date: Thu, 25 Nov 1999 20:25:21 +0100
From: Michael Meskes <meskes@postgresql.org>
To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Subject: [abhijitc@wipinfo.soft.net: A query...]
Message-ID: <19991125202521.B1062@fam-meskes.de>
Mail-Followup-To: PostgreSQL Hacker <pgsql-hackers@postgresql.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i

Anyone out there who could help this guy? Sorry I don't have the time to
check it right now and I don't know it form the top of my headh.

Michael

----- Forwarded message from Abhijit Chatterjee <abhijitc@wipinfo.soft.net> -----

Date: Thu, 25 Nov 1999 20:49:18 +0530
From: Abhijit Chatterjee <abhijitc@wipinfo.soft.net>
To: meskes@postgresql.org
Subject: A query...

Hi,.
I am having a problem and seeking your help to resolve the same.

The problem assumes the following:

- Assume postmaster is running as user 'A'.
- Assume that I give access to a user 'B ' by using 'createdb'.
- User 'A' has a database 'ADB'.
- User 'B' has a database 'BDB'.

Now, can I have the following restrictions:
- 'A 'should be able to access 'ADB' and 'BDB'.
- 'B' should be able to access 'BDB', but not 'ADB'.

Hoping you can resolve this problem.

Thanking you in advance.

regards
Abhijit

Content-Description: Card for abhijit chatterjee

----- End forwarded message -----

--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Thu Nov 25 14:37:55 1999
Received: from hu.tm.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA02157
for <pgsql-hackers@hub.org>; Thu, 25 Nov 1999 14:37:25 -0500 (EST)
(envelope-from hannu@tm.ee)
Received: from tm.ee (localhost [127.0.0.1]) by hu.tm.ee (Postfix) with ESMTP
id CA68272E8; Thu, 25 Nov 1999 21:38:09 +0200 (EET)
Sender: hannu@hu.tm.ee
Message-ID: <383D9021.7D2E2414@tm.ee>
Date: Thu, 25 Nov 1999 21:38:09 +0200
From: Hannu Krosing <hannu@tm.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13-7mdk i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Meskes <meskes@postgreSQL.org>
Cc: pgsql-hackers@hub.org
Subject: Re: [HACKERS] pid file for postmaster?
References: <19991124151159B.t-ishii@sra.co.jp> <9475.943425217@sss.pgh.pa.us>
<19991125082033.D721@fam-meskes.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Michael Meskes wrote:

On Wed, Nov 24, 1999 at 01:33:37AM -0500, Tom Lane wrote:

it. I think the pid file could be placed under $PGDATA. Opinions?

...
$PGDATA seems like the right place to put the file, since we can only
have one active postmaster at a time in a database directory.

Ehem, I think the correct place would be /var/run. At least that's what the
filesystem standard says IIRC.

But that forces us to distinguish between several running backends, with the
main aim of _not_ allowing two distinct backends to be run from the same
$PGDATA.

we could of course start naming them like /var/run/pgsql.pid.for.var.lib.pgsql

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

From bouncefilter Fri Nov 26 01:44:27 1999
Received: from mail.ngi.de ([195.243.0.227])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA24489
for <pgsql-hackers@hub.org>; Fri, 26 Nov 1999 01:43:30 -0500 (EST)
(envelope-from michael@fam-meskes.de)
Received: from p3E9D3E2B.dip0.t-ipconnect.de
(root@p3E9D3E2B.dip0.t-ipconnect.de [62.157.62.43])
by mail.ngi.de (8.9.3/8.9.3) with ESMTP id HAA97442
for <pgsql-hackers@hub.org>; Fri, 26 Nov 1999 07:36:47 +0100 (CET)
(envelope-from michael@fam-meskes.de)
Received: (from michael@localhost)
by tanja.fam-meskes.de (8.9.3/8.9.3/Debian 8.9.3-6) id VAA01646
for pgsql-hackers@hub.org; Thu, 25 Nov 1999 21:05:46 +0100
Date: Thu, 25 Nov 1999 21:05:46 +0100
From: Michael Meskes <meskes@postgresql.org>
To: pgsql-hackers@hub.org
Subject: Re: [HACKERS] pid file for postmaster?
Message-ID: <19991125210546.A1638@fam-meskes.de>
Mail-Followup-To: pgsql-hackers@hub.org
References: <19991124151159B.t-ishii@sra.co.jp> <9475.943425217@sss.pgh.pa.us>
<19991125082033.D721@fam-meskes.de> <383D9021.7D2E2414@tm.ee>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
User-Agent: Mutt/1.0i
In-Reply-To: <383D9021.7D2E2414@tm.ee>;
from hannu@tm.ee on Thu, Nov 25, 1999 at 09:38:09PM +0200

On Thu, Nov 25, 1999 at 09:38:09PM +0200, Hannu Krosing wrote:

But that forces us to distinguish between several running backends, with the
main aim of _not_ allowing two distinct backends to be run from the same
$PGDATA.

Oops. It seems I did not completely read that mail.

we could of course start naming them like /var/run/pgsql.pid.for.var.lib.pgsql

Does not make sense IMO.

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael@Fam-Meskes.De | Use PostgreSQL!

From bouncefilter Thu Nov 25 15:16:05 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 PAA07844
for <pgsql-hackers@hub.org>; Thu, 25 Nov 1999 15:13:46 -0500 (EST)
(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 XAA10884;
Thu, 25 Nov 1999 23:13:07 +0300 (MSK/MSD)
X-Real-To: pgsql-hackers@hub.org
Received: (from dms@localhost)
by woland.wplus.net (8.9.3/8.9.1/wplus.2) id XAA17427;
Thu, 25 Nov 1999 23:13:07 +0300 (MSK)
Message-ID: <XFMail.991125231306.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: <19991125082033.D721@fam-meskes.de>
Date: Thu, 25 Nov 1999 23:13:06 +0300 (MSK)
Sender: dms@woland.wplus.net
From: Dmitry Samersoff <dms@wplus.net>
To: Michael Meskes <meskes@postgreSQL.org>
Subject: Re: [HACKERS] pid file for postmaster?
Cc: pgsql-hackers@hub.org

On 25-Nov-99 Michael Meskes wrote:

On Wed, Nov 24, 1999 at 01:33:37AM -0500, Tom Lane wrote:

it. I think the pid file could be placed under $PGDATA. Opinions?

...
$PGDATA seems like the right place to put the file, since we can only
have one active postmaster at a time in a database directory.

Ehem, I think the correct place would be /var/run. At least that's what the
filesystem standard says IIRC.

I agree ...

---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

From bouncefilter Thu Nov 25 15:31:55 1999
Received: from relay02.chello.nl (relay02.chello.nl [212.83.68.146])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA10299
for <pgsql-general@postgreSQL.org>;
Thu, 25 Nov 1999 15:31:47 -0500 (EST)
(envelope-from jaco@gospelsjop.com)
Received: from gospelsjop.com ([212.83.89.116]) by relay02.chello.nl
(InterMail v4.01.00 201-232-112) with ESMTP
id <19991125203053.EHRS25963.relay02@gospelsjop.com>
for <pgsql-general@postgreSQL.org>; Thu, 25 Nov 1999 21:30:53 +0100
Sender: jaco
Message-ID: <383D9DB0.E2A54358@gospelsjop.com>
Date: Thu, 25 Nov 1999 21:36:01 +0100
From: Jaco de Groot <jaco@gospelsjop.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-22 i486)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: drop/rename table and transactions
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Every now and then I get the following error:

cannot write block 0 of tablename [username] blind

If this happens, all my database connections get this error when trying
to access the database and I need to restart postgresql. The problem
causing this error needs to be something like this:

create table table2 (col1 text);
insert into table2 (col1) values ('some data');
begin work;
drop table table1;
alter table table2 rename to table1;
commit;

I've been playing with some statements to repeat the error, but I
haven't
been able to succesfully repeat the error (only once, but doing the
same didn't cause the error again). Maybe it has something to do with
using multiple connections.

Trying some statements I found an other error, using these statements:

create table table1 (col1 text);
begin work;
drop table table1;
alter table table2 rename to table1;
create table table2 (col1 text);
commit;
select * from table1;

Caused:

couldn't open table1: No such file or directory

I'm using postgresql-6.5.2-1.i386.rpm.

Is the posgresql development team aware of these errors and will
they be fixed?

Gr. Jaco

From bouncefilter Thu Nov 25 16:53:55 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id QAA19062
for <pgsql-hackers@hub.org>; Thu, 25 Nov 1999 16:53:05 -0500 (EST)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id QAA24447;
Thu, 25 Nov 1999 16:52:38 -0500 (EST)
Message-ID: <383DAF7E.592909@southeast.net>
Date: Thu, 25 Nov 1999 16:51:58 -0500
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, tgl@sss.pgh.pa.us, pgsql-hackers@hub.org
Subject: Re: [HACKERS] pid file for postmaster?
References: <199911251835.NAA10783@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Just playing Devil's Advocate.

Having to have root persmission to set up a system is more the rule than the exception,
though. Under Windows NT, for example, you can't create the registry keys except as
an administrator, even though unprivileged users will be setting the values.
Considering what having major DBMS installed could do to the system load, one could
even argue that ONLY an administrator should be allowed to install it!

But that's another issue entirely.....

Bruce Momjian wrote:

Red Hat ALREADY creates a file "postmaster.pid" in the /var/lock directory.
I don't know how far the /var/lock convention goes across different platforms,
but I recommend using IT or its equivalent, I still have scars from my OS/2
days where every product put its goodies in a different place and you had to
guess where, how, and in what format.

Problem with that it is going to require root permission to create that
file or directory if it doesn't exist. I think we have to put it in the
pgsql/data directory. Sorry.

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

From bouncefilter Fri Nov 26 00:27:02 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id AAA13885
for <pgsql-general@postgresql.org>;
Fri, 26 Nov 1999 00:26:24 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id AAA30121;
Fri, 26 Nov 1999 00:23:50 -0500
Sender: mascarm@mascari.com
Message-ID: <383DD367.F0AB3B2C@mascari.com>
Date: Thu, 25 Nov 1999 19:25:11 -0500
From: Mike Mascari <mascarm@mascari.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgresql.org
Subject: Re: [GENERAL] drop/rename table and transactions
References: <3.0.5.32.19991126090804.008af890@pop.mecomb.po.my>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lincoln Yeoh wrote:

If this happens, all my database connections get this error when trying
to access the database and I need to restart postgresql. The problem
causing this error needs to be something like this:

create table table2 (col1 text);
insert into table2 (col1) values ('some data');
begin work;
drop table table1;
alter table table2 rename to table1;
commit;

I did what I did coz I was curious. But creating/Dropping tables in a
transaction does not appear to be a "good thing", and that's not just for
PostgreSQL. I believe doing data definition stuff in transactions is not
recommended.

Is it possible to achieve your goals by using things like
"delete * from table1 where id!=stuffIwant" instead of dropping it?

Cheerio,

Link.

This is one of the few areas that I disagree with the development trend in
PostgreSQL. Every release contains different bugs related to DDL statements in
transactions. The developers appear to want to make them work (i.e., have the
ability to rollback a DROP TABLE, ALTER TABLE ADD COLUMN, etc.). This, in my
opinion, goes far above and beyond the call of duty for a RDBMS. Oracle issues
an implicit COMMIT whenever a DDL statement is found. In fact, one could argue
that those who are porting Oracle apps to PostgreSQL would assume,
incorrectly, than a DROP TABLE in a transaction committed any work done
previously.

I personally believe that PostgreSQL should do the same as Oracle and greatly
simplify the implementation of DDL statements in the backed by issuing an
implicit COMMIT....

Just my opinion, though

Mike Mascari

From bouncefilter Thu Nov 25 20:08:13 1999
Received: from mecomb.com (gw.mecomb.com [161.142.249.98])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA43086
for <pgsql-general@postgreSQL.org>;
Thu, 25 Nov 1999 20:07:39 -0500 (EST)
(envelope-from lylyeoh@mecomb.com)
Received: (from mail@localhost) by mecomb.com (8.8.7/8.8.7) id JAA22670;
Fri, 26 Nov 1999 09:07:34 +0800
Received: from <lylyeoh@mecomb.com> (ilab2.mecomb.po.my [192.168.3.22]) by
ns.mecomb.com via smap (V2.1)
id xma022664; Fri, 26 Nov 99 09:07:25 +0800
Message-Id: <3.0.5.32.19991126090804.008af890@pop.mecomb.po.my>
X-Sender: lylyeoh@pop.mecomb.po.my
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Fri, 26 Nov 1999 09:08:04 +0800
To: Jaco de Groot <jaco@gospelsjop.com>, pgsql-general@postgreSQL.org
From: Lincoln Yeoh <lylyeoh@mecomb.com>
Subject: Re: [GENERAL] drop/rename table and transactions
In-Reply-To: <383D9DB0.E2A54358@gospelsjop.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

If this happens, all my database connections get this error when trying
to access the database and I need to restart postgresql. The problem
causing this error needs to be something like this:

create table table2 (col1 text);
insert into table2 (col1) values ('some data');
begin work;
drop table table1;
alter table table2 rename to table1;
commit;

What happens if two different connections try to "drop table table1"? Try
doing it step by step in two different connections?

I did a vaguely similar thing.

I did a BEGIN, DROP TABLE, ROLLBACK. And yes I know you're not supposed to
be able to rollback a drop table, but I could not recreate the table- I had
to do a manual file system delete of the table. If a connection gets broken
during a transaction, and you get a rollback, you could encounter the same
problem.

I did what I did coz I was curious. But creating/Dropping tables in a
transaction does not appear to be a "good thing", and that's not just for
PostgreSQL. I believe doing data definition stuff in transactions is not
recommended.

Is it possible to achieve your goals by using things like
"delete * from table1 where id!=stuffIwant" instead of dropping it?

Cheerio,

Link.

From bouncefilter Thu Nov 25 20:06:15 1999
Received: from sd.tpf.co.jp (sd.tpf.co.jp [210.161.239.34])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA42930
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 20:06:06 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id KAA04380; Fri, 26 Nov 1999 10:03:45 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Concurrent VACUUM: first results
Date: Fri, 26 Nov 1999 10:08:24 +0900
Message-ID: <001101bf37aa$bcceca20$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <199911251819.NAA10070@candle.pha.pa.us>
Importance: Normal

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

CommitTransactionCommand() is executed at the end of vc_getrels()
and vc_delhilowstats() is executed without StartTransactionCommand().

Oooh, good eye! I wonder how long that bug's been there?

I'm still inclined to remove that call to vc_delhilowstats, because it
seems like a global delete of statistics can't help but be a problem.
But if we keep it, you're dead right: it has to be inside a transaction.

With the new pg_statistic cache, you can efficiently do a heap_insert or
heap_replace dending on whether an entry already exists. In the old
code, that was hard because you had to scan entire table looking for a
match so I just did a delete, and they I knew to do an insert.

I have a anxiety about the index of pg_statistic(pg_statistic itself also
?).

vc_updstats() may be called in immediately committed mode.
vacuum calls TransactionIdCommit() after moving tuples in order
to delete index tuples and truncate the relation safely.

It's necessary but the state is out of PostgreSQL's recovery
mechanism.
heap_insert() is imediately committed. If index_insert() fails
there remains a heap tuple which doesn't have a corresponding
index entry.

Moreover duplicate index check is useless. The check is done
after heap tuples are inserted(and committed).

Should vc_updstats() be moved before TransactionIdCommit() ?
I'm not sure.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Thu Nov 25 21:13:34 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA82644
for <pgsql-hackers@postgresql.org>;
Thu, 25 Nov 1999 21:12:59 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA04980
for <pgsql-hackers@postgresql.org>;
Fri, 26 Nov 1999 11:12:58 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id LAA03287
for <pgsql-hackers@postgresql.org>; Fri, 26 Nov 1999 11:12:57 +0900
To: pgsql-hackers@postgresql.org
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991126111257A.t-ishii@sra.co.jp>
Date: Fri, 26 Nov 1999 11:12:57 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 43

Hi all,

Here is the first draft for the spec of postmaster starting/stopping
tool. I have named it as "pg_ctl."

o pg_ctl [-w] start

start up postmaster. If -w is specified, it will wait for the database
up and running. Options for postmaster should be placed in
$PGDATA/postmaster.conf.

Note: pg_ctl assumes that postmaster writes its pid into
$PGDATA/postmaster.pid.

o pg_ctl [-w][-s|-f|-i] stop

stop postmaster. If -w is specified, it will wait for the database
shutting down.

Shutdown mode can be one of:

-s: smart shutdown (default)
-f: fast shutdown
-i: immediate shutdown

o pg_ctl [-w][-s|-f|-i] restart

just stop and start postmaster.

o pg_ctl status

report the status of postmaster. It would be nice if it could report,
for example, the number of backends running (and their pids) etc. For
this purpose I propose followings:

(1) Add another protocol STATUS_REQUEST_CODE to libpq/pqcomm.h.

(2) Add code to process the protocol in
postmaster/postmaster.c:readStartupPacket().

Comments, suggestions are welcome.
--
Tatsuo Ishii

From bouncefilter Thu Nov 25 23:04:53 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA97365
for <pgsql-hackers@hub.org>; Thu, 25 Nov 1999 23:04:12 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA21454;
Thu, 25 Nov 1999 23:02:57 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911260402.XAA21454@candle.pha.pa.us>
Subject: Re: [HACKERS] pid file for postmaster?
In-Reply-To: <XFMail.991125231306.dms@wplus.net> from Dmitry Samersoff at "Nov
25, 1999 11:13:06 pm"
To: Dmitry Samersoff <dms@wplus.net>
Date: Thu, 25 Nov 1999 23:02:57 -0500 (EST)
CC: Michael Meskes <meskes@postgreSQL.org>, pgsql-hackers@hub.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

[Charset KOI8-R unsupported, filtering to ASCII...]

On 25-Nov-99 Michael Meskes wrote:

On Wed, Nov 24, 1999 at 01:33:37AM -0500, Tom Lane wrote:

it. I think the pid file could be placed under $PGDATA. Opinions?

...
$PGDATA seems like the right place to put the file, since we can only
have one active postmaster at a time in a database directory.

Ehem, I think the correct place would be /var/run. At least that's what the
filesystem standard says IIRC.

I agree ...

I think the idea was to put the file in /data, and symlink to /tmp or
/var/run.

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

From bouncefilter Thu Nov 25 23:12:55 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA99046
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 23:12:07 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA21985;
Thu, 25 Nov 1999 23:11:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911260411.XAA21985@candle.pha.pa.us>
Subject: Re: [HACKERS] Concurrent VACUUM: first results
In-Reply-To: <001101bf37aa$bcceca20$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Nov 26, 1999 10:08:24 am"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Thu, 25 Nov 1999 23:11:25 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have a anxiety about the index of pg_statistic(pg_statistic itself also
?).

vc_updstats() may be called in immediately committed mode.
vacuum calls TransactionIdCommit() after moving tuples in order
to delete index tuples and truncate the relation safely.

It's necessary but the state is out of PostgreSQL's recovery
mechanism.
heap_insert() is imediately committed. If index_insert() fails
there remains a heap tuple which doesn't have a corresponding
index entry.

Huh. Heap_insert writes to disk, but there it is not used unless the
transaction gets committed, right?

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

From bouncefilter Fri Nov 26 04:27:26 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id EAA60047;
Fri, 26 Nov 1999 04:27:19 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id EAA30763;
Fri, 26 Nov 1999 04:24:39 -0500
Sender: mascarm@mascari.com
Message-ID: <383E0BD9.F00E5C43@mascari.com>
Date: Thu, 25 Nov 1999 23:26:02 -0500
From: Mike Mascari <mascarm@mascari.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
References: <14945.943599152@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Mike Mascari wrote:

This is one of the few areas that I disagree with the development
trend in PostgreSQL. Every release contains different bugs related to
DDL statements in transactions. The developers appear to want to make
them work (i.e., have the ability to rollback a DROP TABLE, ALTER
TABLE ADD COLUMN, etc.). This, in my opinion, goes far above and
beyond the call of duty for a RDBMS. Oracle issues an implicit COMMIT
whenever a DDL statement is found.

So, the limits of our ambition should be to be as good as Oracle?
(Only one-half :-) here.)

I've seen quite a few discussions on the mailing lists about
applications that could really use rollback-able DDL commands.

Personally, I certainly wouldn't give up any reliability for this,
and darn little performance; but within those constraints I think
we should do what we can.

regards, tom lane

Well, I agree that it would be GREAT to be able to rollback DDL
statements. However, at the moment, failures during a transaction while
DDL statements occur usually require direct intervention by the user (in
the case of having to drop/recreate indexes) and often require the services
of the DBA, if filesystem intervention is necessary (i.e., getting rid of
partially dropped/created tables and their associated fileystem files). I
guess I'm worried by the current state of ambiguity with respect to which
DDL statements can be safely rolled back and which can't. I know you added
NOTICEs in current, but it seems less than robust to ask the user not to
trigger a bug. And of course, something like the following can always
happen:

test=# CREATE TABLE example(value text);
CREATE
test=# BEGIN;
BEGIN
test=# DROP TABLE example;
NOTICE: Caution: DROP TABLE cannot be rolled back, so don't abort now
DROP

-- someone just yanked the RJ45 cable from the hub in the T-COM closet --

(which, ludicrous as it might seem, happens)

From an otherwise EXTREMELY happy user :-) (full smile...), I see 3

scenarios:

(1) Disallow DDL statements in transactions
(2) Send NOTICE's asking for the user to not trigger the bug until the bugs
can be fixed -or-
(3) Have all DDL statements implicity commit any running transactions.

1, of course, stinks. 2 is the current state and would probably take
several releases before all DDL statement rollback bugs could be crushed
(look how many times it took to get segmented files right -- and are we
REALLY sure it is?). 3, it seems to me, could be implemented in a day's
time, would prevent the various forms of data corruption people often post
to this list (GENERAL) about, and still allows 2 to happen in the future as
a configure-time or run-time option.

Just some ramblings,

Mike Mascari

From bouncefilter Thu Nov 25 23:41:54 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA04053
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 23:41:23 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
XAA26670;
Thu, 25 Nov 1999 23:39:51 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911260439.XAA26670@candle.pha.pa.us>
Subject: Re: your mail
In-Reply-To: <19991126111257A.t-ishii@sra.co.jp> from Tatsuo Ishii at "Nov 26,
1999 11:12:57 am"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Thu, 25 Nov 1999 23:39:51 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi all,

Here is the first draft for the spec of postmaster starting/stopping
tool. I have named it as "pg_ctl."

o pg_ctl [-w] start

start up postmaster. If -w is specified, it will wait for the database
up and running. Options for postmaster should be placed in
$PGDATA/postmaster.conf.

Note: pg_ctl assumes that postmaster writes its pid into
$PGDATA/postmaster.pid.

o pg_ctl [-w][-s|-f|-i] stop

Looks good to me.

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

From bouncefilter Thu Nov 25 23:47:54 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 XAA05096
for <pgsql-hackers@postgreSQL.org>;
Thu, 25 Nov 1999 23:47:26 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id NAA04528; Fri, 26 Nov 1999 13:46:50 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Concurrent VACUUM: first results
Date: Fri, 26 Nov 1999 13:51:29 +0900
Message-ID: <001401bf37c9$e6fc1ea0$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <199911260411.XAA21985@candle.pha.pa.us>
Importance: Normal

I have a anxiety about the index of pg_statistic(pg_statistic

itself also

?).

vc_updstats() may be called in immediately committed mode.
vacuum calls TransactionIdCommit() after moving tuples in order
to delete index tuples and truncate the relation safely.

It's necessary but the state is out of PostgreSQL's recovery
mechanism.
heap_insert() is imediately committed. If index_insert() fails
there remains a heap tuple which doesn't have a corresponding
index entry.

Huh. Heap_insert writes to disk, but there it is not used unless the
transaction gets committed, right?

This could occur only in vacuum.
There's a quick hack in vc_rpfheap().

if (num_moved > 0)
{

/*
* We have to commit our tuple' movings before we'll
truncate
* relation, but we shouldn't lose our locks. And so - quick
hac
k:
* flush buffers and record status of current transaction as
* committed, and continue. - vadim 11/13/96
*/
FlushBufferPool(!TransactionFlushEnabled());
TransactionIdCommit(myXID);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FlushBufferPool(!TransactionFlushEnabled());
}

vc_updstats() may be called in the already committed transaction.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Fri Nov 26 00:10:54 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA12015
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 00:10:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA27725;
Fri, 26 Nov 1999 00:09:25 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911260509.AAA27725@candle.pha.pa.us>
Subject: Re: [HACKERS] Concurrent VACUUM: first results
In-Reply-To: <001401bf37c9$e6fc1ea0$2801007e@cadzone.tpf.co.jp> from Hiroshi
Inoue at "Nov 26, 1999 01:51:29 pm"
To: Hiroshi Inoue <Inoue@tpf.co.jp>
Date: Fri, 26 Nov 1999 00:09:25 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Huh. Heap_insert writes to disk, but there it is not used unless the
transaction gets committed, right?

This could occur only in vacuum.
There's a quick hack in vc_rpfheap().

if (num_moved > 0)
{

/*
* We have to commit our tuple' movings before we'll
truncate
* relation, but we shouldn't lose our locks. And so - quick
hac
k:
* flush buffers and record status of current transaction as
* committed, and continue. - vadim 11/13/96
*/
FlushBufferPool(!TransactionFlushEnabled());
TransactionIdCommit(myXID);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FlushBufferPool(!TransactionFlushEnabled());
}

vc_updstats() may be called in the already committed transaction.

Oh, that is tricky that they have committed the transaction and continue
working in an already committed. Yikes. Any idea why we have to commit
it early?

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

From bouncefilter Fri Nov 26 05:14:27 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id FAA68843
for <hackers@postgreSQL.org>; Fri, 26 Nov 1999 05:13:48 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from mascari.com (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id FAA30914;
Fri, 26 Nov 1999 05:11:12 -0500
Sender: mascarm@mascari.com
Message-ID: <383E16BE.8A3C8B82@mascari.com>
Date: Fri, 26 Nov 1999 00:12:31 -0500
From: Mike Mascari <mascarm@mascari.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
CC: "'PostgreSQL Developers List'" <hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] Re: [GENERAL] drop/rename table and transactions
References:
<219F68D65015D011A8E000006F8590C603FDC196@sdexcsrv1.f000.d0188.sd.spardat.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Zeugswetter Andreas SEV wrote:

Vadim wrote:

The developers appear to want to make them
work (i.e., have the
ability to rollback a DROP TABLE, ALTER TABLE ADD COLUMN,
etc.). This, in my
opinion, goes far above and beyond the call of duty for a
RDBMS. Oracle issues
an implicit COMMIT whenever a DDL statement is found.

And I agreed with this.

And I strongly disagree.
This sounds like pushing the flush button in the toilet,
and instead of the toilet flushing you get a shower.

How could anybody come to the idea that a DDL statement
also does a commit work if inside a transaction ?

Now this sound so absurd, that I even doubt Oracle would do this.

Andreas

I hate to disappoint your faith in Oracle, but....
(from the Oracle 7 SQL Lanugage Reference Manual):

--------------
Transactions

A transaction (or a logical unit of work) is a sequence of SQL
statements that ORACLE treats as a single unit. A transaction
begins with the first executable SQL statement after a COMMIT,
ROLLBACK or connection to the database. A transaction ends with
a COMMIT, ROLLBACK or disconnection (intentional or unintentional)
from the database. Note that ORACLE issues an implicit COMMIT
before and after any Data Definition Language statement.

You can also use a COMMIT or ROLLBACK statement to terminate
a read only transaction begun by a SET TRANSACTION statement.
--------------

Since ORACLE has 70% of the RDBMS market, it is the de facto
standard that the RDBMS will issue an implicit COMMIT when
processing a DDL statement. Like I said before, I would LOVE to
have working support for ROLLBACKs of DDL statements. But I
would prefer to have implicit COMMITs over corrupted indexes,
tables, and mandatory DBA intervention.

Mike Mascari

From bouncefilter Fri Nov 26 00:34:02 1999
Received: from sunpine.krs.ru (SunPine.krs.ru [195.161.16.37])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA15551
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 00:33:07 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id MAA12824;
Fri, 26 Nov 1999 12:32:31 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <383E1B6F.1A0E08EF@krs.ru>
Date: Fri, 26 Nov 1999 12:32:31 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Concurrent VACUUM: first results
References: <199911260509.AAA27725@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

/*
* We have to commit our tuple' movings before we'll truncate

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

* relation, but we shouldn't lose our locks. And so - quick hack:

^^^^^^^^

... or moved tuples may be lost in the case of DB/OS crash etc
that may occur after truncation but before commit...

* flush buffers and record status of current transaction as
* committed, and continue. - vadim 11/13/96
*/
FlushBufferPool(!TransactionFlushEnabled());
TransactionIdCommit(myXID);
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
FlushBufferPool(!TransactionFlushEnabled());
}

vc_updstats() may be called in the already committed transaction.

Oh, that is tricky that they have committed the transaction and continue
working in an already committed. Yikes. Any idea why we have to commit
it early?

Vadim

From bouncefilter Fri Nov 26 00:52:23 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 AAA18131;
Fri, 26 Nov 1999 00:52:06 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id MAA12889;
Fri, 26 Nov 1999 12:46:35 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <383E1EB9.520B5154@krs.ru>
Date: Fri, 26 Nov 1999 12:46:33 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Mike Mascari <mascarm@mascari.com>
CC: Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [GENERAL] drop/rename table and transactions
References: <3.0.5.32.19991126090804.008af890@pop.mecomb.po.my>
<383DD367.F0AB3B2C@mascari.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mike Mascari wrote:

This is one of the few areas that I disagree with the development trend in
PostgreSQL. Every release contains different bugs related to DDL statements in
transactions. The developers appear to want to make them work (i.e., have the
ability to rollback a DROP TABLE, ALTER TABLE ADD COLUMN, etc.). This, in my
opinion, goes far above and beyond the call of duty for a RDBMS. Oracle issues
an implicit COMMIT whenever a DDL statement is found. In fact, one could argue
that those who are porting Oracle apps to PostgreSQL would assume,
incorrectly, than a DROP TABLE in a transaction committed any work done
previously.

I personally believe that PostgreSQL should do the same as Oracle and greatly
simplify the implementation of DDL statements in the backed by issuing an
implicit COMMIT....

Just my opinion, though

And I agreed with this.
But I would like to preserve ability to CREATE TABLE, mostly
because I think that SELECT ... INTO TABLE ... is very usefull
thing.

Vadim

From bouncefilter Fri Nov 26 00:57:23 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA18859
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 00:57:17 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA14681;
Fri, 26 Nov 1999 00:55:55 -0500 (EST)
To: Vadim Mikheev <vadim@krs.ru>
cc: Bruce Momjian <pgman@candle.pha.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Concurrent VACUUM: first results
In-reply-to: Your message of Fri, 26 Nov 1999 12:32:31 +0700
<383E1B6F.1A0E08EF@krs.ru>
Date: Fri, 26 Nov 1999 00:55:54 -0500
Message-ID: <14679.943595754@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vadim Mikheev <vadim@krs.ru> writes:

* We have to commit our tuple' movings before we'll truncate
* relation, but we shouldn't lose our locks. And so - quick hack:

... or moved tuples may be lost in the case of DB/OS crash etc
that may occur after truncation but before commit...

I wonder whether there isn't a cleaner way to do this. What about
removing this early commit, and doing everything else the way that
VACUUM does it, except that the physical truncate of the relation
file happens *after* the commit at the end of vc_vacone?

While I'm asking silly questions: why does VACUUM relabel tuples
with its own xact ID anyway? I suppose that's intended to improve
robustness in case of a crash --- but if there's a crash partway
through VACUUM, it seems like data corruption is inevitable. How
can you pack tuples into the minimum number of pages without creating
duplicate or missing tuples, if you are unlucky enough to crash before
deleting the tuples from their original pages?

regards, tom lane

From bouncefilter Fri Nov 26 01:21:24 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 BAA22209
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 01:21:19 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id PAA04571; Fri, 26 Nov 1999 15:20:07 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>, "Vadim Mikheev" <vadim@krs.ru>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>, <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Concurrent VACUUM: first results
Date: Fri, 26 Nov 1999 15:24:47 +0900
Message-ID: <001501bf37d6$efa41460$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
In-Reply-To: <14679.943595754@sss.pgh.pa.us>
Importance: Normal

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Friday, November 26, 1999 2:56 PM
To: Vadim Mikheev
Cc: Bruce Momjian; Hiroshi Inoue; pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Concurrent VACUUM: first results

Vadim Mikheev <vadim@krs.ru> writes:

* We have to commit our tuple' movings before we'll truncate
* relation, but we shouldn't lose our locks. And so - quick hack:

... or moved tuples may be lost in the case of DB/OS crash etc
that may occur after truncation but before commit...

I wonder whether there isn't a cleaner way to do this. What about
removing this early commit, and doing everything else the way that
VACUUM does it, except that the physical truncate of the relation
file happens *after* the commit at the end of vc_vacone?

I think there exists another reason.
We couldn't delete index tuples for deleted but not yet committed
heap tuples.

If we could start another transaction without releasing exclusive
lock for the target relation,it would be better.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Fri Nov 26 01:39:24 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA23959
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 01:38:50 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA14897;
Fri, 26 Nov 1999 01:36:19 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: "Vadim Mikheev" <vadim@krs.ru>, "Bruce Momjian" <pgman@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Concurrent VACUUM: first results
In-reply-to: Your message of Fri, 26 Nov 1999 15:24:47 +0900
<001501bf37d6$efa41460$2801007e@cadzone.tpf.co.jp>
Date: Fri, 26 Nov 1999 01:36:18 -0500
Message-ID: <14895.943598178@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

I wonder whether there isn't a cleaner way to do this.

I think there exists another reason.
We couldn't delete index tuples for deleted but not yet committed
heap tuples.

My first thought was "Good point". But my second was "why should
vacuum need to deal with that case?". If vacuum grabs an exclusive
lock on a relation, it should *not* ever see tuples with uncertain
commit status, no?

If we could start another transaction without releasing exclusive
lock for the target relation,it would be better.

Seems like that might be doable, if we really do need it.

regards, tom lane

From bouncefilter Fri Nov 26 01:42:27 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 BAA24399
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 01:42:04 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id NAA13141;
Fri, 26 Nov 1999 13:38:32 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <383E2AE8.5C4ADF65@krs.ru>
Date: Fri, 26 Nov 1999 13:38:32 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Hiroshi Inoue <Inoue@tpf.co.jp>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Concurrent VACUUM: first results
References: <001501bf37d6$efa41460$2801007e@cadzone.tpf.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hiroshi Inoue wrote:

Vadim Mikheev <vadim@krs.ru> writes:

* We have to commit our tuple' movings before we'll truncate
* relation, but we shouldn't lose our locks. And so - quick hack:

... or moved tuples may be lost in the case of DB/OS crash etc
that may occur after truncation but before commit...

I wonder whether there isn't a cleaner way to do this. What about
removing this early commit, and doing everything else the way that
VACUUM does it, except that the physical truncate of the relation
file happens *after* the commit at the end of vc_vacone?

I think there exists another reason.
We couldn't delete index tuples for deleted but not yet committed
heap tuples.

You're right!
I just don't remember all reasons why I did as it's done -:))

If we could start another transaction without releasing exclusive
lock for the target relation,it would be better.

So. What's problem?! Start it! Commit "moving" xid, get new xid and go!

Vadim

From bouncefilter Fri Nov 26 01:46:27 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 BAA24936
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 01:45:36 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id NAA13168;
Fri, 26 Nov 1999 13:42:07 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <383E2BBF.4E11CA2D@krs.ru>
Date: Fri, 26 Nov 1999 13:42:07 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Hiroshi Inoue <Inoue@tpf.co.jp>, Bruce Momjian <pgman@candle.pha.pa.us>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Concurrent VACUUM: first results
References: <14895.943598178@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

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

I wonder whether there isn't a cleaner way to do this.

I think there exists another reason.
We couldn't delete index tuples for deleted but not yet committed
heap tuples.

My first thought was "Good point". But my second was "why should
vacuum need to deal with that case?". If vacuum grabs an exclusive
lock on a relation, it should *not* ever see tuples with uncertain
commit status, no?

What if vacuum will crash after deleting index tuples pointing
to heap tuples in old places but before commit? Index will
be broken.

Vadim

From bouncefilter Fri Nov 26 01:54:24 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA26747;
Fri, 26 Nov 1999 01:54:04 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id BAA14947;
Fri, 26 Nov 1999 01:52:32 -0500 (EST)
To: Mike Mascari <mascarm@mascari.com>
cc: Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-reply-to: Your message of Fri, 26 Nov 1999 12:46:33 +0700
<383E1EB9.520B5154@krs.ru>
Date: Fri, 26 Nov 1999 01:52:32 -0500
Message-ID: <14945.943599152@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Mike Mascari wrote:

This is one of the few areas that I disagree with the development
trend in PostgreSQL. Every release contains different bugs related to
DDL statements in transactions. The developers appear to want to make
them work (i.e., have the ability to rollback a DROP TABLE, ALTER
TABLE ADD COLUMN, etc.). This, in my opinion, goes far above and
beyond the call of duty for a RDBMS. Oracle issues an implicit COMMIT
whenever a DDL statement is found.

So, the limits of our ambition should be to be as good as Oracle?
(Only one-half :-) here.)

I've seen quite a few discussions on the mailing lists about
applications that could really use rollback-able DDL commands.

Personally, I certainly wouldn't give up any reliability for this,
and darn little performance; but within those constraints I think
we should do what we can.

regards, tom lane

From bouncefilter Fri Nov 26 01:57:24 1999
Received: from ns1.prima.net.id ([202.57.0.8])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA27466
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 01:56:31 -0500 (EST)
(envelope-from chai@prima.net.id)
Received: from prima.net.id (chai@[202.57.0.54]) by ns1.prima.net.id
(8.8.4/8.7.2) with ESMTP id GAA29017;
Fri, 26 Nov 1999 06:59:30 +0700 (GMT)
Sender: chai@ns1.prima.net.id
Message-ID: <383E2ED1.EB07B13F@prima.net.id>
Date: Fri, 26 Nov 1999 13:55:13 +0700
From: Chairudin Sentosa Harjo <chai@prima.net.id>
Reply-To: chai@prima.net.id
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tatsuo Ishii <t-ishii@sra.co.jp>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: pg_ctl
References: <19991126111257A.t-ishii@sra.co.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

How about adding pg_ctl [-w] restart?

It will automatically stop and start the database again.

Chai

Tatsuo Ishii wrote:

Hi all,

Here is the first draft for the spec of postmaster starting/stopping
tool. I have named it as "pg_ctl."

o pg_ctl [-w] start

start up postmaster. If -w is specified, it will wait for the database
up and running. Options for postmaster should be placed in
$PGDATA/postmaster.conf.

Note: pg_ctl assumes that postmaster writes its pid into
$PGDATA/postmaster.pid.

o pg_ctl [-w][-s|-f|-i] stop

stop postmaster. If -w is specified, it will wait for the database
shutting down.

Shutdown mode can be one of:

-s: smart shutdown (default)
-f: fast shutdown
-i: immediate shutdown

o pg_ctl [-w][-s|-f|-i] restart

just stop and start postmaster.

o pg_ctl status

report the status of postmaster. It would be nice if it could report,
for example, the number of backends running (and their pids) etc. For
this purpose I propose followings:

(1) Add another protocol STATUS_REQUEST_CODE to libpq/pqcomm.h.

(2) Add code to process the protocol in
postmaster/postmaster.c:readStartupPacket().

Comments, suggestions are welcome.
--
Tatsuo Ishii

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

From bouncefilter Fri Nov 26 02:02:24 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 CAA28585
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 02:01:24 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id NAA13245;
Fri, 26 Nov 1999 13:58:33 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <383E2F97.2ECD92F6@krs.ru>
Date: Fri, 26 Nov 1999 13:58:31 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, Hiroshi Inoue <Inoue@tpf.co.jp>,
pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Concurrent VACUUM: first results
References: <14679.943595754@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

While I'm asking silly questions: why does VACUUM relabel tuples
with its own xact ID anyway? I suppose that's intended to improve
robustness in case of a crash --- but if there's a crash partway
through VACUUM, it seems like data corruption is inevitable. How
can you pack tuples into the minimum number of pages without creating
duplicate or missing tuples, if you are unlucky enough to crash before
deleting the tuples from their original pages?

VACUUM:
1. has to preserve t_xmin/t_xmax in moved tuples
(or MVCC will be broken) and so stores xid in t_cmin.
2. turns HEAP_XMIN_COMMITTED off in both tuple versions
(in old and new places).
3. sets HEAP_MOVED_IN in tuples in new places and
HEAP_MOVED_OFF in tuples in old places.

Seeing HEAP_MOVED_IN/HEAP_MOVED_OFF (this is tested for
tuples with HEAP_XMIN_COMMITTED off only, just to don't
test in all cases) tqual.c funcs will check is tuple->t_cmin
committed or not - ie was VACUUM succeded in moving or not.
And so, single vacuum xid commit ensures that there will be
neither duplicates nor lost tuples.

Sorry, I should to describe this half year ago, but...

Vadim

From bouncefilter Fri Nov 26 02:12:25 1999
Received: from sapphire.albourne.com (root@sapphire.albourne.com
[195.212.241.227]) by hub.org (8.9.3/8.9.3) with ESMTP id CAA30497
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 02:12:13 -0500 (EST)
(envelope-from a.joubert@albourne.com)
Received: from isadora.cy.albourne.com (akamas.albourne.com [195.212.241.254])
by sapphire.albourne.com (8.9.3/8.9.3/Albourne/CYS/1.8/MAPS) with
ESMTP id JAA18626; Fri, 26 Nov 1999 09:16:07 +0200 (EET)
Received: from albourne.com (localhost [127.0.0.1])
by isadora.cy.albourne.com (8.9.3/8.9.3/Albourne/CYC/1.4) with ESMTP id
JAA16390; Fri, 26 Nov 1999 09:12:09 +0200 (EET)
Sender: a.joubert@albourne.com
Message-ID: <383E32C9.7533ABF2@albourne.com>
Date: Fri, 26 Nov 1999 09:12:09 +0200
From: Adriaan Joubert <a.joubert@albourne.com>
Organization: APL Financial Services (Overseas) Ltd
X-Mailer: Mozilla 4.7 [en] (X11; I; OSF1 V4.0 alpha)
X-Accept-Language: en
MIME-Version: 1.0
To: Bruce Momjian <maillist@candle.pha.pa.us>
CC: Postgresql <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
References: <199910091020.GAA05654@candle.pha.pa.us>
Content-Type: multipart/mixed; boundary="------------9E38936425C3CD788D4FE732"

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

Bruce Momjian wrote:

I can integrate the type for you into the include/catalog files if
everyone agrees they want it as a standard type and not an contrib type.

Hi,

Attached are the C-routines that implement a BIT and BIT VARYING type.
I know Bruce said he would integrate them, but he is writing a book at
the moment as well, so if somebody can explain to me how to go about
integrating it, or would like to have a go, go ahead.

If any functions are missing, let me know and I will add them. This
should implement concatenation and substr as defined in the SQL
standard, as well as comparison operators. I've also added all the
normal bit operators.

I developed the C routines outside the postgres source tree, only using
postgres.h and copying bits from ctype.h. I hope it will be fairly easy
to integrate.

Any comments welcome.

Adriaan
--------------9E38936425C3CD788D4FE732
Content-Type: application/octet-stream;
name="bitstr.tgz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="bitstr.tgz"

H4sIAHwqPjgAA+w9/VvbRtL91f4rtrQEyZbBMgSSGLtHSEh4LoG8wPWlbdo8sr3GCrakSnKA
Jrm//WZmP7SSP4AEuF6LnwRk7e7M7Ox870p0/DRJ45VvbvPD1uobG3X2DWu46411+M0ebrhr
+Ft96oxt1N2NtcZD92GDMdd9WF//hj28VarkZ5ykXszYN14v9j0vmNkv4Sf9YXoXFN3ppyPW
/4MXw9Xy4FZwuPX6+vrs9V996K6K9V+tr6+tP4T1X208XP2G1W+FmsLnb77+3/lBdzjucbYQ
hUl6EvNkebBQLqcXEe/xPkPxeMRY5UcvfuqnTX1/7AfpaoPBvd2gx8+b5fJ3cNsPOHv5/PjZ
7gvrDxuXFn5tunX2A7PgqrpUX7LZE7quufXq0taSXc4GPt09Onzz/ODpT0fPS6VH+vaPWwfQ
8vLZweHPpVLi/8HDvkXI7fJKhe2NRx0es1BQyvyApQM/wS8MxNoPTlhlpQDq1fM9683RgV0q
WZYFncbdlIH4D3ngsYoNfZ5tHW1RD7vW/jB8Bw2E6k0IaAFXGgEOzvp+nKSsc5Fy1g2D1PMD
xGYg7nmpN4n98Fq4AUZxmoBQzpMLFAnvpn4YYKM3d+LIWYnegjuHuz8/p2+shh2Iw+JS8VtM
2+v1EByAR5QGAi+lOzzoTeJ6s/VMTbSIvGIstManFmXqbAMOMtdjaQiYw5jnp0nTPvE/8IAB
G0/SwSQxyFREIPDA7MXFiklIlb0tl+ADMitaF83WNkMhdkF467buWtJcq05wLZLC0uEXIfBH
8WmSidbQP6U2y8ZVPTx6pcSJx4k9OZfne5qxllDOis3wjiBCL6rg5GsvOQWMsFJn/nAIkD8A
Tfzc66bDCxYCUGSww/xlvmzqn1AmAze0vd46/CfMuX6+s2Pefrn74iUrfurnj+qg2d0BWNYK
+yMCcH5gia8JoAtS1huPRhcOY8KOeGkKlmUU9uxmblQ4TtWwQksytUm4savj6oThECfLf2dy
iBefuA7T1w2jE0z48k4nV+qUXqHT8CqQhvMg4dyhT3cUzekkOQf9PBBQ2Y+ZHdlEzzC+Ysfz
K/cMwtTsmWtLBn4ftOVkkOsi1jYZ9NPJzkPev0rfrjePfQbMcQfU1ejqSFlK1MUQ+v+3XfkX
ffLxX/dWcGD8tzYz/ltb32hsqPh/bWNtA+O/VYz/7+O/2/+sVGo39SmzSlnb4OUuXIM33RkH
FJ4krA+2gJzf2B+mNYxgIJZE7QLPh6YHxl3IEMqylyWw3WfP9452d3a3t4529/cEyO9fcq/H
4+9Fl5skHxze1HA4u6vypAXwrsZtr9vlSbIySMdRvj9YGG8YnqxEJ+9wuvnGceoPkxXihx8Q
IqAAPuC4y6AYb2Lwsuc8eVImPfkjwp+1GvuDx2EtgrAMYiLs0FOBTxZWiBEfULBxhMFa1QF7
eNIRYhcZdCS0RBLeZLQCq4YGw2GwlrCe5YLfN/AIQCPv3B+NRxLgMiO0RzpypQB4HPM89n44
HIZnCIcP+YgHqeIAG9DC05TyJJ4NwuEEUAsZLcfYRVIZzQXDy2VmeQnERwDNgxhJzUEiQJi4
comCkIu5gZAo9j94aSEW17KOjMiTlWSUkJMnLHJC4OBm8rxcwl8ESzLAg/wj8U8Cv+93vUDm
IiItkYuM4rRCeiRjMFYrCx0ChkMoCMR5Cg1E14iYwtbAG7KYR0AscN/LZReiN6qnmsVRJjCQ
efU4jB9BcNgDeghikE/RYv772I+hORqOEwOMDqZFzI8CFoejLFoD4SHKrePjYxHRIboBh4Xu
8K43TkAKOIu8JCHDApLDPCFPsCgYg4PbHqM0MQMprpMXx97FOz9YBqZEPuYZkEE6LAiZ3+Me
iBYECbAaI+4FyQ8/2GQmRCBQvlZkW/4IKy96AmPHw9QhLYdxUbNUMnIG+CnWAjtDqA635Boh
aiZz8krcLBMSZL5DAF5drhMEQEmeGDUthc4JIFOjEhjTnILJD6Kx0Vt8aIyMQN9BdPduwM+b
ogkA1FkL1u5cD3JbOYQ5AL7DOl3gLZi8pp7+ucMummW0J36fWQlrtdjev169Eloac5hsQDea
2AUQbg94V6ZCWfaeMdhHTeig1HkBO5e4EfAv9V9braXOEvv0ickvT5dsVtYarOYGE3KRPD4E
STSGnptDj2cNreuh1MzBZ1jPDw72Dxy2IKXsCVtMkE6MlD0wU0O/lynkgoNZUFmsEcCDu3Bh
JZjcE1nAgmdKNQ3DQzqWWz8lYhIOLrnkxbcGybYhRqzSYmvYSaA5DEc89Uegw1r2FdnJOIqG
oGLLbLePOgW31S1UXszz0Q6NvFMuuJSgzOpF07OF5UvBbu+FqdGa2Rk/6HO0MCTPYBoFrA6Y
KbABWMEZeEFhCEjB2BuKEaLcAEIHTAkDSJRh8kCdF8vFAfHyqCTimSKMIQzOEazeKBRUB2xV
uksvyXfGekUioeFAiB/GMXoRuSzjCNiwptNwwf+MnSDsNVcsgXFTLoeSJGrGceJ2O+v54EFO
+kA8i12qq9gpv+ClWWKZL8ZgiY4t9pDvxA4wRLGfpiAmZNdwStZiz15wEKDhBh0zL0dJFgKY
r+Dk+ojZYbc2e+2db6VpfAjI7TkalEUNIu4cjRMiccjRbeCKLfaIMssAWFOuqWZWecwylqBG
WHWgWfoDG7wRRDJdJNGWOpjwFCW8zpJQSG5F2J7hmXeBthfIBMVOQHhRLIir2G6GfCQPIz4C
UJZyJHWHKSSqCCSabCBHykRWaMuaND+Vmfz/TAtRyotqh9ZC1rJIqEEtREnOT2VAIvV2aliy
zBLh5BIVbVBbh/eFwuDliR8EOoDNgiHTOCURGqYqmbUY2a3rYKrEKieoDJcpxoLAj2Xtid54
ccK1y5uMeiiCMLDLYcCo0yA8w4n3lYpLc3gGl91wFHmxYGSmeBoAmnxZPGuWs1DE6nTJF+AU
v8U5ovmFicL3ahW9YLUKevgRNQfnBZED+BR3yRaqBKL0qcXOm6q50221Nmz2UbRK0OJLDj/d
iatVuvosvZDs1m6TWyt9FlR+znmpqVxEi3I1Ll4648Jc262l+hLaJbjebC09Rl+qZyOEwKaO
4PNwq6EpTJZ0xwLAlgFgZy6ArSWs9Lr1aVA8A0p/LhRvAoroa5inhW1hKSNi4WI3cxY9/8RP
FxwAZRuLOn1FK7CA2fLLVdQd5eKSjECfzc010U0t7Ody2fQVYFAzSyuXuRhDgVXqo13XUp1X
RamDMHmEB0GILQQdozht1nGXwNBVQoLpRCdMU4xLsC/5QGUI0FyIMJk0C3xtrO0VmHE0k4qc
FQryITsL0r618BRHLh6D8cDyIF4t9t4GwNvYsYAnm5vMelRDfLbNHqhyt3BRs9txW0ASLpEi
Cy01wHAQE0NtGisV4VK3moahiF1IZ9B1gQcVoT3mOtKXms5RLqkMhAWPm+XPVFtQlXVWk5mQ
ylYxagM2IkZMpZB1jEOaeAGrjRFOYoQwwuKRGMA/3MSAQEnCE4tBURDZwW4qfGs2IxwN/g3y
sgTSQTAUMHg07g7EIN4H1+HDXYO+YQgUyMETKZi5F6DTrBKJu3SQIlsSu5jonyKZPGEnn5yn
Y4RP07MKZe5m+vmG3cx1gZgfei3Vlgq3Xbr9ti7vK6OaQ6Ij8MxtJxq8aBFdVtZAx6TeLq61
s32q5mXkIpQqW9Mdya9OOtMMLWq4EiVxh6wOzOV4qXjn7ZK+BSJ3hsks9yg6RrdJQk3bUiqA
6I+HQ5n6kxabwY52Fn4LPIW/iavE/Gqr4Qg3gXZO4pW7z2h+7XYb5zatBfSwfr6j5/U5I/QF
iK4HRg73xpKURzL2J13AoIw0QKYNYgKeSG3AeqeghRMRixdckEzriaBg+a0WuTlwcHGtNod1
ZK7zkjJbpRNTp9/EIs7K/K4o30zoTvKFyiNPBjD0OKYqnTrsz6NFs1XoLrTi6TytKAh0zfAW
JNzGd0PMMcbAglG5RONPcfzpZm7sKXZFh/DRiAxgCufC+2DMZ4ORgLgRzMQSsk9GL5ubItbL
FEL91lgN0k9bPqImXTzNYrUrYctwff5K2ZflTbXvS+J/E+XNTEmut6V8X+RT5uC+bHdftrsv
2+XKdm1dtbvFspyyV9esy5lbd19enxNdr1ecywi+r87lq3MqIflfK81hxUMX50TYeHe1ub9W
ae2+RnZfI7u9GtkNlKumupt8vco82PMVdSu4jfPT1asYfkBUlJCHp+OoBWSJMIPDIRPnakSq
sE2VeT9BCxJx8N5hnMjDRmBhKXAgblEFgNOBjO6UIaoSl6+GqUiADjYgXWSCeyreTrwRuF3v
ggabXqNw/kkVuujMA4LKh0wJHtX0Yh2fjQNv1PFPxuEYptxB3lBikVHd4ekZBxGjkyAGWgNV
kQRNwW4/Ix2i1zFHrDJ0QHgUPXi5oo1R/UhU+wRoEajRiuJQBDUxfADjT8DZYagvGOugO6Oz
zB10CicQF2om/QxwkswRaodVSO5UBJT4owgWG+CAR8RVUmt4gcBGHjVhWWfiZD2ySrYb3nSZ
Sit0MrfcmXukmJJEmTXBtFzHiMobWa5UiWBYJWroaOpb+QjCbvIjphEWArYxTpzS0LBzOZWF
ZNkiX5FYc4URApU1NoqNDdNh0+hvVXzSmIlIxC05IcPT+yKayjTDE8W/oHDqn2yUhAoBVXcU
WdaHELInelCCYgmi2plyt2GDaSmZTx5QVxvzzTrZE7VMcw51/w2Wyf2TLtO3apkEYQAUdTIz
34A3PQsNO0U6KahIIMuimNtlPR5BOEwmIGBnAw7KHWd1BASnztjBREeQDvDYYfx3SCnphKOw
L1neKQ6SLbOtoUw5PXF0MfF7mLiSzcessNfzMUKFxJRMG3VFe4EJsqwsE1aJcqWY34ZIp4Pg
OD7W4pMF9vMeg0wxGOJwPOyhIVI2Wp7M2wrkpg3MjCaE3n8ciOc2esJUoWiXO/OfD5jQAVr1
CW3Qt6fqhYAAaG5cRSQtWg0MIWqSYCuyJnsIVcFq3QiTFim6eZHNi+prP7D07BVgW2scDG+1
6ioUnKu9l+jvTA1WRSjJCtVjU4P7AWSfPRFqbRRMifWG0Zvz1AgteJ7VlpARIt+hTvIAUh7m
JYb0UpibLdq0MkDOeZbmaiDbkyBvYOZy4ivqERJhlgK44oFOTQ1zam65dOY/dDJF3QoKRndc
MAJ00aDt7Gah5mzqYIw66N2E4umy7Jc6pkwdZ9SN3KoSdKmaM2s2Ek5FPg8qEsoZBRbZd36R
RaPGburQwGKPiX94UmDCwDiF2TtZvia8mCwqbYfRhfnEqI5DwaeqalE3urAKBRJnmikynWQR
vDzmbMSpqibsFvNJvVrSzmAHsl252sN0uqqzGJF5dBo9YW7t/D6dYeMa7Xp+bzBf7RJHNvBs
Pk5TkEFlKsits7qP1gZRfzGeMJUTVNWgyJtWljKMLwrAnMrVJANqbq7SxJqIY9N4YFMAh7tq
s5oQ4M9PkICDfrJ2O5uAmXc3y6VI1I+QXTDABCsJohqVAEmwNjfVlA1I+b3u2YdDOuppN7Rq
0CP2IQbBbTS6mas0ZpJGKRglqQ6jzQ631vESEWeww/97xXqxBwuzvuzW2WPzBD3FH1d5uq5g
GEXwEZtf9AXWLuQVsVNeqzAESQS7yt3MarKi2Rx5ySlue6PtTObZzrkWsmgDSbw4nV0c4mWC
JvS1d24ljtBGTjcgyuCOgFDNtDRx2xIqGGvubrqT1dI9XR0majwI1UFnivXRaeb3aodFdKdp
ZrRuNE6vcGPFbWqNE0jf/6fDzvgSSNoJbZOl8ZgbIoeP6KXykfMoTCi6BvZBrIPxNoi/jPLN
Zo7NetaxXhK4n2h9ncaMWG9ifCVLYlW/v5QxxIOtmJ5g6YI912rmyTJ8OMaCz8UP+WMkFrLA
Nh9UF0ZcVIQB5E88ctQemIKrs7aSmH6tlT16k3uOnaqfl/smuyrIMJ+mdwRrSp9VwCqruoqu
Hf8EdwixUjUIz8TJr7OiwRc+DU+HdbGqKUn2lY2fnDwRPH/PATpEyQzzj0XoyanQmCmHj6qq
ov1R7ZNVpAFOwAD7RUPeVL1o3arVKLGLHgLteElsNCCQdjtfkRUQNZxYl6s/Z6cocLc4NDmJ
jj97TYMpPnNLzPKUEvbBuq9aOTSLwrvS6UfwM2JzH91PUUSMojZ70KKhzVwlfZb3AY2mWiCP
geuoAcPwxO9CAru19wzTeJn3ZyXSIx0U0F7dOA1HEIXDiCEV8sCUUGjeUxtbySCM6dUMxtOS
uQB9/nPw2hNlDmde/O2qAyBRQ13FN5sGl5UZQ8+hjIwOzNQ3GX9dasyutUEpMU6JgnXYL+L+
yJ16iErHoVFjVrsIyi495m9qaEbVZJCai0dJjeWa0PEjWC74/QAXC9VLlcbUK1BkuV2+jsRL
oCdkenXSMmirC/WaI9thPF209w9uSbKXC6I993UMNyLZZgh1L+d/ajn/pORcS7mRYMnUdMLi
T/UY4LW0jZ+rAOezNOD4zlRg/itJ7nXgL68DKu3I6cJvmc2X8ckdaQQ4lOkasbd/hBrh5fSh
IMvFl+aY0jtPbL9AVudI5Ew5M0RyVnHO7DJL8opJNMrQLBG6hgRhmWYiBod7eBwozgwmwPp3
JbpLI6nfYISC0cPNc3qdkUh8LHpXlzqjZW5xZ4eh7Mm3SBQE57KXJGXlFsgW34kyiiqnXEO4
vkicqJJxAlb+A5dzplO+MikUExcvg8qO+wLNsJSqgJltj2RvjrJogjX5Cqj/gtReKpZlZnAb
q0RAaj4TNbJfmvEiKzSTWkzXC0zIMvBSAinLkyBxqyQ7xnQY8a4PVqjrJfwJlSW8QMiiqAio
TNIsoGh7i6eX87h0ISF2WJSdhsxOSlZpa6PuGOPEaSB1SAs7z1PbWJRWjVS8EulE3MxqMfme
mnur1Htm5i1cg0nI1HIsI2KY3qyrZOsuty3nV1+1yGr1F9J+4/o/741qf3YDQLbrivqPff8+
6j/DKwq+HnLzOQp1uMlwaHT6OXeGeZpWTjMdudjqGhbkGjYksyJVUyxzBmVGjTlm1dYUeKSb
9aYkeVcf8Dbf7pp/BHGW1lPgIJ9E1HaEKfNTkpYntmdv4MjyIRitaebnmls5V37/W0e//y/l
yS29AHD++5/dRt1d1+9/3qiv4fv/1tbd+/f/3cXn6i+80/c2k7Tnh8uDdrmMh59S8hN4LAwE
+FETj9mK28Kwdn7B5zQ/soWn9bpbX3DgwnXr9I++1OE2Xhyv7rgNumhsUMOCI+U8/1k4lgNB
qly4/Czec6oPEQt0eARM/s//Y9AfXeE1KHQzEp/dIIlsw2GPHbbuMPcR/HfpUtCMRJbLdF6O
ziK86/HU84cJs8YBnjjlPaae2GXaU/vZ0QVmLciH99RL7pCsJ/KdB8p9JcK/FYfIZwQpbDCG
PFVP0Jo5+CPMwTN4amMEsWmwi8eLx2zBSX7xf2231+j3A/X0tTppATjEoRqcc3nkAdmWOTWH
vc8ijuQXFLZfyaflqwF4X9LwMU/ELj4rh4/i4Ww6QIJ0F0gNLIZ6kRu2kMPL1kp3XVnJrYWV
ZE3ZXHFzSSDRLyagfk72rDV9z46667Fvg+3912+2DnYP9/cOnwiOzJpeNvP3LR8fBXkvG9+r
RuMUS8I2W20mSOtp0pLptL3/VZ/gkIefsI9DDTL3Ngne294CT0Yv57xZkj99YkVmXk5xdluc
szJpN4lH2g//9fTw6EATbaC2FnsOPqdATCtiXwVsrvMIMeawic1q6oDttn1tqI8vgfpYQb0e
qY8vIfXx9YGuOg/nAoX2LwE6n9LVL6PU3bgEqrthF+zg2+DV/ovd7a1XuOV4s1L94GuF2gt6
s4Q6R/n+wQ2r49cSHsZXovv4pgn/7WsJP5+gnPKfKbTv7R9dhXZF3L+vRJio8kqnIZ+8NXAf
vtzdOWKvnu9chjrnEJEzU9BKbyaZW0fWtgzPT/5uGpvfpourPfhBMN/nic8ycGLie3u66xPz
ONh98fJPPRFRSpw7k7cBq+gP5no/7e69MG5dY3aXxy365RRzA5dKIXCxmzKnNeKWyZBlMraZ
xen7OOY+jrmPY+7jmPs45j6OuY9j/nfjmGuUje8/f5GPrP+/9k553x/yW8Ex/+//MNbI/v7P
Qxc64N9/bKzd1//v4rO982rrxSEY8NpJWb7r7glTu0Gh+mM+Ybn0vbW9bTP4SQNsVgvZ9/9g
3/+mRi2HT/Sf/lEXg7KGlAE1WsvdIfeCJ+VSPGK1PqtohPeG6K4+Uv+zzZ9bwHHZ339dbbiM
rW9srLsb69gA+r++dq//d/L5zu/jWwHYm/3DoxcHzw/fvdR/3dG4NXXzT/0tWNqVwQMc2Z+H
NTepICR5NNFC53SxyV2faKMdH3zur4lnYhQ1+HAd06+WYHXb+POU/2nv7HrbtqEwfG3+Cg0D
FjtwvC5Lt6AusiVbLwys2JYEw4AgHWSZjrVKlquPJt7Xb995zyEpylGUBeiGXYgXqUqRFL9J
WTzPi1OgIEuOgtoNh3f42D7cAj+K6xe4HtVxwrv2OCcPx9k5xmJYniNzfEUytz+q/T+ydMu6
stwHPJTy+3hRl54rA38PG36fH+LvUe23TLKwlL+e7yKr5okWb6+6m98LK24L+U0IxzaOHarw
XnhpoEpayIan/D0YAeURVWDvAZT5exGQBzkrNA1aHEU8ac2Z1A+8OUft8dpyKJUIb5O3tohe
TpVf/UdBGCVxqVNP4ni2Zowntd5g8Mz50n9tx8jmv+qonNEbPY7jCUrA+qFT1AlQ58K5r2pN
e/yyWoelTrZjsL1WQa5vNnkWsYnjub75ga71AmZzsOarCoGK2ZxSUjbCtOHpx5zujNn94XB/
Wa2jXzYlOrG8ltni+BFdhx8NvFJuJO8fQHcPYroXRjrt8MWA9gBxiN5sgJAMVYFKF1PDmK31
QcT+WjLPmWkKM7c9jqPvBPtdDbinDQYiGj1VAyZpD0TH+eqz66n60+tFP3lqva1y0Lsa1F5E
JxP9WEQWkPYitupo1xNwMyWcHAinD90t9V05bYwVnqkOj6+Or5t9kGZF8XQ5YXocJbjQee48
wZULlvIOq/x52qI+A5zEeFbfkhN7Qcr/qI9hBLzsd45Pc2b/d/7q9NvXr/6lZzzy/vf8+bMv
nP4rbf1wJOzoy/7813/iTi3k8JsaqFhmAdh4rL0JsPbFj98dgCaYxOHaB5iwoqlSl3ygNNH1
619DzjM6WDoN2EbKvMqdzS4xvyv8az6WTYIz3OG5nhc7F0VAZLoABDaGDViDqjhW+i7Sm1JA
iUgwbopJMIiwwLnUZexUUyfBDNwBgC4QQjGki9GdUUb7XSYYCkeMawOY3KKIsTr5wE1LJwTT
kF5fKfa7KmYQpwls4Y25dmjBPKMbaQErnzSMVlL1CLbI1nulWoWULdkHfcrPGIaC4mWsJBCI
4XpL9QM2wFcjaofZ2gO1u8acBZxQWBRVyuKWxh6cUap5oEOjEvGuyuj1XFH9nu1NJpM9ANB+
5ivTxOB4OPIkczJlGi480uQ4kM9RVt2lZiIpR84U6Rd6ZKEla3OgKb02phZZO4gac1+MTVSd
RntEI2T/1/iP8SfjN+OXL/lJJycwI2SdGkXbpmWV4PAyMGy3oeEdQ4JXyDkwz6mhlzBH9Jl4
sLfKlsp1OrM/4QPp2fqmZvjT02rTxKG5RGluBTGpuP5yHSZBtsENZk9ujJ0xa9H+xjTLiPlu
4I7THpEWRupUuDYQHIVfht+MbIXaQ9yrsE3G15pGWmSLlDHXik/XG1lWHpisikp9izl0gRu9
OGYNHVRWcJFWnAmLE62hYLqWvaXO8lo0XhK9uOFBYn9bcLjSDc8D1GI31JpCZMdgHwO7PdtL
g1W2gckCd9UiS/U8W2z5+LiNYwYoC0gjs6lmXh9XE+UPcQIaT0yAVfQs1nCF2XZhILg0wjQb
l1IfdCPlFiNrod/TPmQDAGxVAuzHzeWKUGRVHmG20PRI0Qym0kdvQeTTeWHgX/WvKWLBKhrE
CpNkweOedrcGM8t5DdNUCCZmqJmX7UUgMRhhb39mW5lV8+DARz0ZZWTUiHLTsAvIfcMUU9W/
w9nbYbDUtwGMah39218LzAzvVJkb4N3wfRgn2KxD3NmYkjxJFpe2yefAmTNhcoci6+HrRRg6
T82chOaWeYo/fTSe7AvaUOqshPNw2vRccKQl2WYRiienNI/XYb61ObOJPU1CpFEhO2rU/7RO
1NUlrxM84qSjYZwUmuZpDB8qGBaJZUOc3UP08nSkatYyj3IRBKOHpkxuibI8p3e2ZHvtCjrv
pttRyc7isrkueN3GfdLuRkFRKheODLSD5p0I6Q8+HfzdqQvUQX+tA3VgCL1AXcW2gToYiV6g
rpQMAqsL2Un108q49qq5m3Ay9UJ2Gsv7AbvN6v2Qu0bL/r1H7dLuBe4wYjXdTWoAvRx7pCVW
NkGjspXQ7qowDjZQS9D+WkfxTuXtgPZgcvF1mMxpKaBVhDY/o/6ls3e9613vete73vWud73r
Xe9617ve/Y/d32Su5EYAoAAA
--------------9E38936425C3CD788D4FE732--

From bouncefilter Fri Nov 26 04:04:26 1999
Received: from mecomb.com (gw.mecomb.com [161.142.249.98])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA57137
for <pgsql-general@postgreSQL.org>;
Fri, 26 Nov 1999 04:04:03 -0500 (EST)
(envelope-from lylyeoh@mecomb.com)
Received: (from mail@localhost) by mecomb.com (8.8.7/8.8.7) id RAA30115
for <pgsql-general@postgreSQL.org>; Fri, 26 Nov 1999 17:03:59 +0800
Received: from <lylyeoh@mecomb.com> (ilab2.mecomb.po.my [192.168.3.22]) by
ns.mecomb.com via smap (V2.1)
id xma030110; Fri, 26 Nov 99 17:03:30 +0800
Message-Id: <3.0.5.32.19991126170409.00841b20@pop.mecomb.po.my>
X-Sender: lylyeoh@pop.mecomb.po.my
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32)
Date: Fri, 26 Nov 1999 17:04:09 +0800
To: pgsql-general@postgreSQL.org
From: Lincoln Yeoh <lylyeoh@mecomb.com>
Subject: Re: [GENERAL] locking/insert into table and transactions
In-Reply-To: <3.0.5.32.19991126090804.008af890@pop.mecomb.po.my>
References: <383D9DB0.E2A54358@gospelsjop.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Hi,

I'd like to prevent duplicate ids from being inserted into a table. I can
let the database enforce it by using UNIQUE or PRIMARY KEY. But assuming I
prefer to catch such things with the application, what would be the best
way of doing it?

The only way I figured to do it was to use:
begin;
lock table accounts;
select count(*) from accounts where id=$number;
if count=0, insert into accounts (id,etc) values ($number,$etc)
commit;

Is this a good idea? Or is it much better and faster to let the database
catch things?

Is it faster to use "select count(*) from accounts" or "select id from
accounts"?

Apparently count(*) has some speed optimizations in MySQL. So wondering if
there are similar things in Postgres.

Thanks,

Link.

From bouncefilter Fri Nov 26 04:38:26 1999
Received: from gandalf.telecom.at (gandalf.telecom.at [194.118.26.84])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA61548
for <hackers@postgreSQL.org>; Fri, 26 Nov 1999 04:38:23 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id KAA46480
for <hackers@postgreSQL.org>; Fri, 26 Nov 1999 10:38:18 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <XQ9JB0DV>; Fri, 26 Nov 1999 10:38:18 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC196@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'PostgreSQL Developers List'" <hackers@postgreSQL.org>
Subject: AW: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date: Fri, 26 Nov 1999 10:38:15 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"

Vadim wrote:

The developers appear to want to make them
work (i.e., have the
ability to rollback a DROP TABLE, ALTER TABLE ADD COLUMN,
etc.). This, in my
opinion, goes far above and beyond the call of duty for a
RDBMS. Oracle issues
an implicit COMMIT whenever a DDL statement is found.

And I agreed with this.

And I strongly disagree.
This sounds like pushing the flush button in the toilet,
and instead of the toilet flushing you get a shower.

How could anybody come to the idea that a DDL statement
also does a commit work if inside a transaction ?

Now this sound so absurd, that I even doubt Oracle would do this.

Andreas

From bouncefilter Fri Nov 26 05:12:27 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 FAA68681
for <hackers@postgreSQL.org>; Fri, 26 Nov 1999 05:12:25 -0500 (EST)
(envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id RAA14579;
Fri, 26 Nov 1999 17:12:02 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <383E5CF1.10B7B3BE@krs.ru>
Date: Fri, 26 Nov 1999 17:12:01 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
CC: "'PostgreSQL Developers List'" <hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] Re: [GENERAL] drop/rename table and transactions
References:
<219F68D65015D011A8E000006F8590C603FDC196@sdexcsrv1.f000.d0188.sd.spardat.at>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Zeugswetter Andreas SEV wrote:

RDBMS. Oracle issues
an implicit COMMIT whenever a DDL statement is found.

And I agreed with this.

And I strongly disagree.
This sounds like pushing the flush button in the toilet,
and instead of the toilet flushing you get a shower.

How could anybody come to the idea that a DDL statement
also does a commit work if inside a transaction ?

Now this sound so absurd, that I even doubt Oracle would do this.

Standard says (4.41 SQL-transactions):

It is implementation-defined whether or not the non-dynamic or
dynamic execution of an SQL-data statement or the execution of
^^^^^^^^^^^^^^^^^^
an <SQL dynamic data statement> is permitted to occur within the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
same SQL-transaction as the non-dynamic or dynamic execution of
^^^^^^^^^^^^^^^^^^^^^^^
an SQL-schema statement. If it does occur, then the effect on any
^^^^^^^^^^^^^^^^^^^^^^^

So, you see that this idea came not to Oracle only...

I don't object against DDLs inside BEGIN/END.
I just mean that it's not required by standard.
If someone is ready to fix this area - welcome.

Vadim
P.S. Is DROP TABLE rollback-able in Informix, Andreas?

From bouncefilter Fri Nov 26 05:30:27 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 FAA71659
for <hackers@postgreSQL.org>; Fri, 26 Nov 1999 05:30:01 -0500 (EST)
(envelope-from ZeugswetterA@wien.spardat.at)
Received: from sdexcgtw01.f000.d0188.sd.spardat.at
(sdexcgtw01.f000.d0188.sd.spardat.at [172.18.1.16])
by gandalf.telecom.at (xxx/xxx) with ESMTP id LAA84270;
Fri, 26 Nov 1999 11:29:49 +0100
Received: by sdexcgtw01.f000.d0188.sd.spardat.at with Internet Mail Service
(5.5.2448.0) id <XQ9JB0RM>; Fri, 26 Nov 1999 11:29:48 +0100
Message-ID:
<219F68D65015D011A8E000006F8590C603FDC199@sdexcsrv1.f000.d0188.sd.spardat.at>
From: Zeugswetter Andreas SEV <ZeugswetterA@wien.spardat.at>
To: "'Vadim Mikheev'" <vadim@krs.ru>
Cc: "'PostgreSQL Developers List'" <hackers@postgreSQL.org>
Subject: AW: AW: [HACKERS] Re: [GENERAL] drop/rename table and transaction
s
Date: Fri, 26 Nov 1999 11:29:44 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="windows-1252"

So, you see that this idea came not to Oracle only...

I don't object against DDLs inside BEGIN/END.

Yes, I know. All I object against is, that a DDL statement commits
my previous update/insert/delete statements.

I just mean that it's not required by standard.
If someone is ready to fix this area - welcome.

imho it is ok, to disallow ddl inside transaction,
until somebody fixes rollback.

Vadim
P.S. Is DROP TABLE rollback-able in Informix, Andreas?

Yes.

Andreas

From bouncefilter Fri Nov 26 09:23:30 1999
Received: from bologna.nettuno.it (bologna.nettuno.it [193.43.2.1])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA99347
for <pgsql-hackers@postgresql.org>;
Fri, 26 Nov 1999 09:22:51 -0500 (EST)
(envelope-from jose@sferacarta.com)
Received: from proxy.sferacarta.com (mail@sfcabop1.nettuno.it
[193.207.10.213])
by bologna.nettuno.it (8.9.3/8.9.3/NETTuno 4.1) with ESMTP id PAA01310;
Fri, 26 Nov 1999 15:22:45 +0100 (MET)
Received: from rosso.sferacarta.com (sferacarta.com) [10.20.30.5]
by proxy.sferacarta.com with esmtp (Exim 2.05 #1 (Debian))
id 11rNzo-0006b7-00; Fri, 26 Nov 1999 16:13:16 +0000
Message-ID: <383E9854.A3E71A41@sferacarta.com>
Date: Fri, 26 Nov 1999 15:25:24 +0100
From: jose soares <jose@sferacarta.com>
X-Mailer: Mozilla 4.5 [it] (Win95; I)
X-Accept-Language: it
MIME-Version: 1.0
To: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
CC: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] substring extraction
References: <Pine.LNX.3.96.991125184601.3411A-100000@ara.zf.jcu.cz>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Try this:

--returns the $2 field delimited by $3
drop function field(text,int,text);
create function field(text,int,text) returns text as
'declare
string text;
pos int2:= 0;
pos1 int2:= 0;
times int2:= 0;
totpos int2:= 0;
begin
times:= $2 - 1;
string:= $1;
while totpos < times loop
string:= substr(string,pos+1);
pos:= strpos(string,$3);
totpos:= totpos + 1;
end loop;
string:= substr(string,pos+1);
pos1:= strpos(string,$3);
return substr(string,1,pos1 - 1);
end;
' language 'plpgsql';

select field('primo.secondo.terzo',1,'.');
field
-----
primo
(1 row)

select field('primo.secondo.terzo',2,'.');
field
-------
secondo
(1 row)

select field('primo.secondo.terzo',3,'.');
field
-----
terzo
(1 row)

Jos�

Karel Zak - Zakkr ha scritto:

Hi,

I need in the SELECT query extract substring 'cccc' from string
'aaa.bbbbb.cccc.dd.eee' (extract third field from string if
delimiter is '.').

It is easy if I know where is begin/end of 'cccc' and I can
use the substring() function:

select substring('aaa.bbbbb.cccc.dd.eee' from 11 for 4);
substr
------
cccc

But how extract it if I don't know where is position of the second
and third '.'?

Yes, I know the function position() or textpos(), but this return first
a position of the substring...

For this exist nice UN*X command "cut -f3 -d." , but how make it in
SQL?

I ask about it, because I write for me this as new function in C, but
I'm not sure if not exist other (better) way for it.

Karel

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

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

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

From bouncefilter Fri Nov 26 09:30:35 1999
Received: from wilk.lupus.pl (root@wilk.lupus.pl [195.116.206.178])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA08129
for <pgsql-hackers@postgresql.org>;
Fri, 26 Nov 1999 09:29:45 -0500 (EST)
(envelope-from grzegorz_przezdziecki@lupus.waw.pl)
Received: from lupus.waw.pl ([195.116.206.134])
by wilk.lupus.pl with ESMTP id QAA09588
for <pgsql-hackers@postgresql.org>; Fri, 26 Nov 1999 16:15:10 +0100
Message-ID: <383E996B.C4557033@lupus.waw.pl>
Date: Fri, 26 Nov 1999 15:30:03 +0100
From: Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?=
<grzegorz_przezdziecki@lupus.waw.pl>
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
CC: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Vacuum
References: <12989.943543036@sss.pgh.pa.us>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit

Thanks

Tom Lane wrote:

Grzegorz =?iso-8859-2?Q?Prze=BCdziecki?= <grzegorz_przezdziecki@lupus.waw.pl> writes:

vacuum;
NOTICE: Index tb_klienci_id_klienci_key: NUMBER OF INDEX' TUPLES (8776)
IS NOT THE SAME AS HEAP' (8774)

There are some bugs here that we are looking into fixing for 7.0.
In the meantime, you should be able to get rid of the message by
dropping and recreating that index.

regards, tom lane

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

--

/*****************************/
void main(void)
{
Co to zrobic();
zeby dobrze zrobic();
i sie nie narobic();
return(TRUE);
}
/*****************************/

From bouncefilter Fri Nov 26 09:50:30 1999
Received: from ara.zf.jcu.cz (zakkr@ara.zf.jcu.cz [160.217.161.4])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA15058
for <pgsql-hackers@postgresql.org>;
Fri, 26 Nov 1999 09:50:06 -0500 (EST) (envelope-from zakkr@zf.jcu.cz)
Received: from localhost (zakkr@localhost)
by ara.zf.jcu.cz (8.9.3/8.9.3/Debian/GNU) with SMTP id PAA31449;
Fri, 26 Nov 1999 15:36:46 +0100
Date: Fri, 26 Nov 1999 15:36:45 +0100 (CET)
From: Karel Zak - Zakkr <zakkr@zf.jcu.cz>
To: jose soares <jose@sferacarta.com>
cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] substring extraction
In-Reply-To: <383E9854.A3E71A41@sferacarta.com>
Message-ID: <Pine.LNX.3.96.991126151247.30394A-100000@ara.zf.jcu.cz>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 26 Nov 1999, jose soares wrote:

Try this:

--returns the $2 field delimited by $3
drop function field(text,int,text);
create function field(text,int,text) returns text as
'declare
string text;
pos int2:= 0;
pos1 int2:= 0;
times int2:= 0;
totpos int2:= 0;
begin
times:= $2 - 1;
string:= $1;
while totpos < times loop
string:= substr(string,pos+1);
pos:= strpos(string,$3);
totpos:= totpos + 1;
end loop;
string:= substr(string,pos+1);
pos1:= strpos(string,$3);
return substr(string,1,pos1 - 1);
end;
' language 'plpgsql';

Oh, it is great! But my implementation in C for this is
a little longer (only) :-)

I send this question to the hacker list because "extract delimited
substring" is not a abnormal uses's request, and (IMHO) will very
good if this will in PgSQL. How much uses known write this in
C or any PL?

'C' implementafion "extract delimited substring":
-----------------------------------------------
text
*strcut( text *string, char *d, int field )
{
char *ptr = NULL,
*p = NULL,
*pe = NULL;
text *result = NULL;
int siz;

ptr = VARDATA(string);
*(ptr+ (VARSIZE(string) - VARHDRSZ)) = '\0';

for(p = ptr; *p != '\0'; p++) {
if (field == 1)
break;
if (*p == (int) d)
--field;
}
if (!*p)
return textin("");

for(pe = p; *pe != '\0'; pe++) {
if (*pe == (int) d)
break;
}

result = (text *) palloc(sizeof(text) * (siz = pe - p) + VARHDRSZ);
strncpy(VARDATA(result), p, siz);

*(VARDATA(result) + siz) = '\0';
VARSIZE(result) = siz + VARHDRSZ;
return result;
}

CREATE FUNCTION strcut(text, char, int)
RETURNS text
AS '@module_dir@'
LANGUAGE 'c';

template1=> select strcut('aaa.bbb.ccc', '.', 2);
strcut
------
bbb

Karel

From bouncefilter Fri Nov 26 10:39:31 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA20438
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 10:38:45 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA15712;
Fri, 26 Nov 1999 10:38:07 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Subject: Re: pg_ctl
cc: pgsql-hackers@postgreSQL.org
In-reply-to: Your message of Fri, 26 Nov 1999 11:12:57 +0900
<19991126111257A.t-ishii@sra.co.jp>
Date: Fri, 26 Nov 1999 10:38:06 -0500
Message-ID: <15710.943630686@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Here is the first draft for the spec of postmaster starting/stopping
tool. I have named it as "pg_ctl."
o pg_ctl [-w] start
start up postmaster.

How will pg_ctl know what to start --- where do the database directory,
port number, and path (to locate the postmaster executable) come from?

Options for postmaster should be placed in
$PGDATA/postmaster.conf.

Port number could reasonably be kept there, but I'm less sure about
path, and for sure there must be another way for pg_ctl to find PGDATA
in the first place...

It would be nice if it could report,
for example, the number of backends running (and their pids) etc. For
this purpose I propose followings:

(1) Add another protocol STATUS_REQUEST_CODE to libpq/pqcomm.h.

(2) Add code to process the protocol in
postmaster/postmaster.c:readStartupPacket().

Security issues may be a factor here. Do you want just anyone anywhere
on the net to be able to extract the postmaster status? If not, how
shall we restrict it?

regards, tom lane

From bouncefilter Fri Nov 26 11:07:31 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 LAA25162
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 11:06:33 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org ([207.144.78.32])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id LAA00151;
Fri, 26 Nov 1999 11:06:25 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re:
Date: Fri, 26 Nov 1999 11:04:10 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
References: <19991126111257A.t-ishii@sra.co.jp>
In-Reply-To: <19991126111257A.t-ishii@sra.co.jp>
MIME-Version: 1.0
Message-Id: <99112611085601.00541@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Thu, 25 Nov 1999, Tatsuo Ishii wrote:

Here is the first draft for the spec of postmaster starting/stopping
tool. I have named it as "pg_ctl."

Tatsuo, are you implementing this? If so, feel free to get the startup script
from the RedHat RPM set and cannibalize. This pg_ctl command is going to
greatly simplify startup scripts.

The RPM startup script is /etc/rc.d/init.d/postgresql, and can also get fetched
from my site at
http://www.ramifordistat.net/postgres/unpacked/non-beta/postgresql.init.6.5.3

If you're not implementing pg_ctl, I can take a stab at it.

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

From bouncefilter Fri Nov 26 11:15:31 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA26052;
Fri, 26 Nov 1999 11:14:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA15862;
Fri, 26 Nov 1999 11:13:44 -0500 (EST)
To: Mike Mascari <mascarm@mascari.com>
cc: Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-reply-to: Your message of Thu, 25 Nov 1999 23:26:02 -0500
<383E0BD9.F00E5C43@mascari.com>
Date: Fri, 26 Nov 1999 11:13:44 -0500
Message-ID: <15860.943632824@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Mike Mascari <mascarm@mascari.com> writes:

Well, I agree that it would be GREAT to be able to rollback DDL
statements. However, at the moment, failures during a transaction while
DDL statements occur usually require direct intervention by the user (in
the case of having to drop/recreate indexes) and often require the services
of the DBA, if filesystem intervention is necessary (i.e., getting rid of
partially dropped/created tables and their associated fileystem
files).

And forced commit after the DDL statement completes will improve that
how?

I see 3 scenarios:

(1) Disallow DDL statements in transactions
(2) Send NOTICE's asking for the user to not trigger the bug until the bugs
can be fixed -or-
(3) Have all DDL statements implicity commit any running transactions.

1, of course, stinks. 2 is the current state and would probably take
several releases before all DDL statement rollback bugs could be crushed

It's not an overnight project, for sure.

3, it seems to me, could be implemented in a day's
time, would prevent the various forms of data corruption people often post
to this list (GENERAL) about,

I don't believe either of those assumptions. We've had problems with
VACUUM's internal commit, and I don't think it'd be either quick or
inherently more reliable to apply the same model to all DDL commands.

A more significant point is that implicit commit is not a transparent
change; it will break applications. People use transaction blocks for
two reasons: (1) to define where to roll back to after an error, (2) to
ensure that the results of logically related updates become visible to
other backends atomically. Implicit commit destroys both of those
guarantees, even though only the first one is really related to the
implementation problem we are trying to solve.

As a user I'd be pretty unhappy if "SELECT ... INTO" suddenly became
"COMMIT; SELECT; BEGIN". Not only would that mean that updates made
by my transaction would become visible prematurely, but it might also
mean that the SELECT retrieves results it should not (ie, results from
xacts that were not committed when my xact started). Both of these
things could make my application logic fail in hard-to-find, hard-to-
reproduce-except-under-load ways.

So, although implicit commit might look like a convenient workaround at
the level of Postgres itself, it'd be a horrible loss of reliability
at the application level. I'd rather go with #1 (hard error) than
risk introducing transactional bugs into applications that use Postgres.

Since ORACLE has 70% of the RDBMS market, it is the de facto standard

Yes, and Windows is the de facto standard operating system. I don't use
Windows, and I'm not willing to follow Oracle's lead when they make a
bad decision...

regards, tom lane

From bouncefilter Fri Nov 26 12:49:32 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA38594
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 12:48:38 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
MAA15855;
Fri, 26 Nov 1999 12:46:36 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911261746.MAA15855@candle.pha.pa.us>
Subject: Re: [PATCHES] A bag of psql goodiesu
In-Reply-To: From "(env:" "pgman)" at "Nov 25, 1999 11:22:59 pm"
To: peter_e@gmx.net
Date: Fri, 26 Nov 1999 12:46:36 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Peter, is there a way from pgsql to show if an index is unique? It
would be nice.

test=# create table x(y int);
CREATE
test=# create unique index xx on x(y);
CREATE
test=# \d xx
Table "xx"
Attribute | Type | Info
-----------+------+------
y | int4 |

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

From bouncefilter Fri Nov 26 13:17:33 1999
Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net
[194.217.242.39]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA43082
for <hackers@postgresql.org>; Fri, 26 Nov 1999 13:17:13 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1)
id 11rPvD-0001Ay-0B; Fri, 26 Nov 1999 18:16:39 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id SAA26747; Fri, 26 Nov 1999 18:16:12 GMT
Message-Id: <199911261816.SAA26747@mtcc.demon.co.uk>
Date: Fri, 26 Nov 1999 18:16:12 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] run_check problem
To: tgl@sss.pgh.pa.us
Cc: hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: FpNR5Dgn5Af02kCkZmc0iQ==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

Tom Lane <tgl@sss.pgh.pa.us>

Keith Parks <emkxp01@mtcc.demon.co.uk> writes:

This is due to 2 problems.
1) The awk script is broken over 2 lines.
2) Solaris's awk does not seem to understand REs in split(). (nawk's OK)

I don't think so --- the exact same split() construct is there in the
old regress.sh test driver, same as it ever was. I can believe the line
break is a problem, but if there's another problem then you need to
keep digging.

Comparing the two scripts, I wonder if Jan broke it by adding '/bin/sh'
to the invocation of config.guess. Doesn't seem very likely, but...

Unfortunately, the old script was broken too. It's just that
I'd not noticed as I'd included a patch to change awk to nawk
my auto build script.

I tried different pernutations of quotes, brackets n'all last
night and came to the conclusion that it couldn't be done with
solaris awk. (I'm not very patient though ;-( )

anyone for sed and tr ?

From bouncefilter Fri Nov 26 13:58:33 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id NAA60979
for <hackers@postgreSQL.org>; Fri, 26 Nov 1999 13:58:29 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
NAA16906;
Fri, 26 Nov 1999 13:49:48 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911261849.NAA16906@candle.pha.pa.us>
Subject: Re: [HACKERS] run_check problem
In-Reply-To: <199911261816.SAA26747@mtcc.demon.co.uk> from Keith Parks at "Nov
26, 1999 06:16:12 pm"
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Date: Fri, 26 Nov 1999 13:49:48 -0500 (EST)
CC: tgl@sss.pgh.pa.us, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I tried different pernutations of quotes, brackets n'all last
night and came to the conclusion that it couldn't be done with
solaris awk. (I'm not very patient though ;-( )

anyone for sed and tr ?

Sure. Just don't use any non-standard tr character classes like :alpha:.

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

From bouncefilter Fri Nov 26 14:24:37 1999
Received: (from news@localhost) by hub.org (8.9.3/8.9.3) id OAA80932
for pgsql-hackers@postgresql.org; Fri, 26 Nov 1999 14:23:53 -0500 (EST)
(envelope-from news)
X-Authentication-Warning: hub.org: news set sender to <news> using -f
From: "Iradm" <iradmt@aha.ru>
X-Newsgroups: alt.japanese.neojapan.hackers.nifty,
alt.japanese.neojapan.hackers.pay-site,
alt.japanese.neojapan.hackers.swpw,
alt.japanese.neojapan.hackintosh,
comp.databases.postgresql.hackers, fido.cardinal.pvt,
fido.cards.ita
Subject: Credit Kard 100$
Date: Fri, 26 Nov 1999 22:23:25 +0300
Organization: Mr. Postman
Lines: 10
Sender: iradmt@p209.n88.dip.aha.ru
Message-ID: <81mmo6$eod$1@news2.aha.ru>
X-Trace: news2.aha.ru 943644230 15117 195.2.88.209 (26 Nov 1999 19:23:50 GMT)
X-Complaints-To: abuse@zenon.net
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.00.2417.2000
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
To: pgsql-hackers@postgresql.org

Hi All
I need now 1 real credit card number, and experiance date! I need your help!
Maby i help you and in 2 month i get you your money back with post help, ore
in other method/ Thank you for help!
I'am sorry for my english!

Mail me, if you wohnt to help: wottak@yahoo.com
Best REGARDS FROM BRUT!

From bouncefilter Fri Nov 26 14:52:34 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA84737;
Fri, 26 Nov 1999 14:52:19 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from ferrari (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id OAA02196;
Fri, 26 Nov 1999 14:49:38 -0500
Message-Id: <199911261949.OAA02196@corvette.mascari.com>
From: "Mike Mascari" <mascarm@mascari.com>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Lincoln Yeoh" <lylyeoh@mecomb.com>, <pgsql-general@postgreSQL.org>,
"PostgreSQL Developers List" <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date: Fri, 26 Nov 1999 14:48:20 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Tom Lane <tgl@sss.pgh.pa.us> writes:
Mike Mascari <mascarm@mascari.com> writes:

Well, I agree that it would be GREAT to be able to rollback DDL
statements. However, at the moment, failures during a transaction

while

DDL statements occur usually require direct intervention by the user

(in

the case of having to drop/recreate indexes) and often require the

services

of the DBA, if filesystem intervention is necessary (i.e., getting rid

of

partially dropped/created tables and their associated fileystem
files).

And forced commit after the DDL statement completes will improve that
how?

Because 99% of the instances of index and data corruption I've seen
have come from rolled-back DDL statements - usually because the on
disk representation no longer matches the system catalogue. A forced
commit on DDL changes against tables and indexes with access
exclusive locks will make that operation as close to "atomic" as
possible...

As a user I'd be pretty unhappy if "SELECT ... INTO" suddenly became
"COMMIT; SELECT; BEGIN". Not only would that mean that updates made
by my transaction would become visible prematurely, but it might also
mean that the SELECT retrieves results it should not (ie, results from
xacts that were not committed when my xact started). Both of these
things could make my application logic fail in hard-to-find, hard-to-
reproduce-except-under-load ways.

What does ORACLE do here?

So, although implicit commit might look like a convenient workaround at
the level of Postgres itself, it'd be a horrible loss of reliability
at the application level. I'd rather go with #1 (hard error) than
risk introducing transactional bugs into applications that use Postgres.

Since ORACLE has 70% of the RDBMS market, it is the de facto standard

Yes, and Windows is the de facto standard operating system. I don't use
Windows, and I'm not willing to follow Oracle's lead when they make a
bad decision...

regards, tom lane

So I guess I should file away my other suggestion to use DCOM as
the object technology of choice instead of CORBA? ;-)

From bouncefilter Fri Nov 26 15: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 PAA87010;
Fri, 26 Nov 1999 15:09:35 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org ([207.144.78.58])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id PAA00394;
Fri, 26 Nov 1999 15:09:12 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: "Mike Mascari" <mascarm@mascari.com>, "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date: Fri, 26 Nov 1999 15:04:20 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: "Lincoln Yeoh" <lylyeoh@mecomb.com>, <pgsql-general@postgresql.org>,
"PostgreSQL Developers List" <hackers@postgresql.org>
References: <199911261949.OAA02196@corvette.mascari.com>
In-Reply-To: <199911261949.OAA02196@corvette.mascari.com>
MIME-Version: 1.0
Message-Id: <99112615114107.00541@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Fri, 26 Nov 1999, Mike Mascari wrote:

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

What does ORACLE do here?

Since ORACLE has 70% of the RDBMS market, it is the de facto standard

Yes, and Windows is the de facto standard operating system. I don't use
Windows, and I'm not willing to follow Oracle's lead when they make a
bad decision...

So I guess I should file away my other suggestion to use DCOM as
the object technology of choice instead of CORBA? ;-)

This is a Free Software project -- PostgreSQL is not bound by the decisions of
the 'market leader' any more than Linux is bound by the standards of Microsoft.

Having said that, at the same time, a run-time option to mimic Oracle's
behavior might be useful to all of those folk who are trying to port Oracle
applications over to PostgreSQL -- particularly if the SQL is compiled in.

However, someone who is interested in such an option will probably have to
implement it as well, as it certainly appears to not be a priority issue at
this point.

In cases where Oracle diverges from the SQL-92 or SQL3 standards, should we go
'standard' -- or go 'non-standard' -- the choice should be clear.

We are not competing directly against Oracle, AFAICT -- we serve a different
role altogether.

And I say that while I want an Oracle-specific application to run under
PostgreSQL.

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

From bouncefilter Fri Nov 26 15:39:36 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA90548;
Fri, 26 Nov 1999 15:39:29 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from ferrari (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id PAA02358;
Fri, 26 Nov 1999 15:30:39 -0500
Message-Id: <199911262030.PAA02358@corvette.mascari.com>
From: "Mike Mascari" <mascarm@mascari.com>
To: "Lamar Owen" <lamar.owen@wgcr.org>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Lincoln Yeoh" <lylyeoh@mecomb.com>, <pgsql-general@postgresql.org>,
"PostgreSQL Developers List" <hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date: Fri, 26 Nov 1999 15:32:04 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

From: Lamar Owen <lamar.owen@wgcr.org>
On Fri, 26 Nov 1999, Mike Mascari wrote:

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

What does ORACLE do here?

Since ORACLE has 70% of the RDBMS market, it is the de facto

standard

Yes, and Windows is the de facto standard operating system. I don't

use

Windows, and I'm not willing to follow Oracle's lead when they make a
bad decision...

So I guess I should file away my other suggestion to use DCOM as
the object technology of choice instead of CORBA? ;-)

This is a Free Software project -- PostgreSQL is not bound by the

decisions of

the 'market leader' any more than Linux is bound by the standards of

Microsoft.

The DCOM remark was just a joke ;-). My remark concerning ORACLE was in
response to Andreas' comment that implicit COMMITs of DDL statements was
absurd. I wanted to simply point out that, since ORACLE has 70% market
share,
most corporate database developers EXPECT their DDL statements to commit
their transactions (if they've RTFM). I also pointed out that it would be
GREAT
if PostgreSQL could successfully rollback DDL statements sanely (and thus
diverge from ORACLE). I guess I don't expect that to happen successfully
until
something the equivalent of TABLESPACES is implemented and there is a
disassociation between table names, index names and their filesystem
counterparts and to be able to "undo" filesystem operations. That, it seems
to
me, will be a major undertaking and not going to happen any time soon...

I'll stop swinging at windmills now...

Mike Mascari

From bouncefilter Fri Nov 26 16:54:35 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 QAA99066;
Fri, 26 Nov 1999 16:54:26 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org (dial-22.r11.ncbrvr.infoave.net [207.144.78.86])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id QAA00486;
Fri, 26 Nov 1999 16:54:18 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: "Mike Mascari" <mascarm@mascari.com>, "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date: Fri, 26 Nov 1999 16:51:55 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: "Lincoln Yeoh" <lylyeoh@mecomb.com>, <pgsql-general@postgresql.org>,
"PostgreSQL Developers List" <hackers@postgresql.org>
References: <199911262030.PAA02358@corvette.mascari.com>
In-Reply-To: <199911262030.PAA02358@corvette.mascari.com>
MIME-Version: 1.0
Message-Id: <99112616564608.00541@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Fri, 26 Nov 1999, Mike Mascari wrote:

The DCOM remark was just a joke ;-). My remark concerning ORACLE was in
response to Andreas' comment that implicit COMMITs of DDL statements was
absurd. I wanted to simply point out that, since ORACLE has 70% market
share,

I did not see the response to Andreas, nor did I see Andreas' assertion that it
was absurd. My apologies.

counterparts and to be able to "undo" filesystem operations. That, it seems
to
me, will be a major undertaking and not going to happen any time soon...

Yes, that is true. As long as the storage manager relies on the filesystem for
table names, this will be a problem, unless filesystem deletions are delayed
until COMMIT, and filesystem creates are undone at a ROLLBACK.

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

From bouncefilter Fri Nov 26 17:51:36 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 RAA06248
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 17:50:38 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from mcadnote1 (ppm215.noc.fukui.nsk.ne.jp [210.161.188.90])
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id HAA04928; Sat, 27 Nov 1999 07:48:03 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Vadim Mikheev" <vadim@krs.ru>
Cc: "Tom Lane" <tgl@sss.pgh.pa.us>, "Bruce Momjian" <pgman@candle.pha.pa.us>,
<pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Concurrent VACUUM: first results
Date: Sat, 27 Nov 1999 07:48:05 +0900
Message-ID: <NDBBIJLOILGIKBGDINDFAECHCBAA.Inoue@tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="Windows-1252"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <383E2AE8.5C4ADF65@krs.ru>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

Hiroshi Inoue wrote:

Vadim Mikheev <vadim@krs.ru> writes:

* We have to commit our tuple' movings before we'll truncate
* relation, but we shouldn't lose our locks. And so - quick hack:

... or moved tuples may be lost in the case of DB/OS crash etc
that may occur after truncation but before commit...

I wonder whether there isn't a cleaner way to do this. What about
removing this early commit, and doing everything else the way that
VACUUM does it, except that the physical truncate of the relation
file happens *after* the commit at the end of vc_vacone?

I think there exists another reason.
We couldn't delete index tuples for deleted but not yet committed
heap tuples.

You're right!
I just don't remember all reasons why I did as it's done -:))

If we could start another transaction without releasing exclusive
lock for the target relation,it would be better.

So. What's problem?! Start it! Commit "moving" xid, get new xid and go!

After a thought,I remembered that members of xidHash hold xids.
Must I replace them by new xid ?
Seems it isn't a cleaner way than current.

There's another way.
We could commit and start Transaction after truncation and
before vc_updstats().
One of the problem is that cache invalidation is issued in vc_
updstats().
It is preferable that cache invalidation is called immedately
after/before truncation,isn't it ?
Any other problems ?

BTW how(or what) would WAL do when vacuum fails after
TransactionIdCommit() ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Fri Nov 26 18:31:37 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 SAA10636
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 18:31:08 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11rUgu-0003kJC; Sat, 27 Nov 99 00:22 MET
Message-Id: <m11rUgu-0003kJC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] substring extraction
To: zakkr@zf.jcu.cz (Karel Zak - Zakkr)
Date: Sat, 27 Nov 1999 00:22:12 +0100 (MET)
Cc: jose@sferacarta.com, pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <Pine.LNX.3.96.991126151247.30394A-100000@ara.zf.jcu.cz> from
"Karel Zak - Zakkr" at Nov 26, 99 03:36:45 pm
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Karel Zak wrote:

On Fri, 26 Nov 1999, jose soares wrote:

Try this:

--returns the $2 field delimited by $3
drop function field(text,int,text);
create function field(text,int,text) returns text as
'declare
string text;
pos int2:= 0;
pos1 int2:= 0;
times int2:= 0;
totpos int2:= 0;
begin
times:= $2 - 1;
string:= $1;
while totpos < times loop
string:= substr(string,pos+1);
pos:= strpos(string,$3);
totpos:= totpos + 1;
end loop;
string:= substr(string,pos+1);
pos1:= strpos(string,$3);
return substr(string,1,pos1 - 1);
end;
' language 'plpgsql';

Oh, it is great! But my implementation in C for this is
a little longer (only) :-)

I send this question to the hacker list because "extract delimited
substring" is not a abnormal uses's request, and (IMHO) will very
good if this will in PgSQL. How much uses known write this in
C or any PL?

What about this one:

create function field(text,int,text) returns text as '
return [lindex [split $1 $3] $2]
' language 'pltcl';

It does all the work as long as the third argument is a
single character. For multibyte delimiters it will be
slightly bigger, but not much. Now you might imagine why
PL/Tcl was the first language I created.

Jan

--

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

From bouncefilter Fri Nov 26 21:05:38 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA27560
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 21:05:34 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA05560;
Sat, 27 Nov 1999 11:05:32 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id LAA13100;
Sat, 27 Nov 1999 11:05:32 +0900
To: lamar.owen@wgcr.org
Cc: pgsql-hackers@postgreSQL.org
Subject: Re:
In-Reply-To: Your message of "Fri, 26 Nov 1999 11:04:10 -0500"
<99112611085601.00541@lorc.wgcr.org>
References: <99112611085601.00541@lorc.wgcr.org>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991127110531L.t-ishii@sra.co.jp>
Date: Sat, 27 Nov 1999 11:05:31 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 14

Tatsuo, are you implementing this?

Yes.

If so, feel free to get the startup script
from the RedHat RPM set and cannibalize. This pg_ctl command is going to
greatly simplify startup scripts.

Thanks. I know that the script is very convenient since I've been
using the script for a while:-) This is one of the reason why I start
to implemnt pg_ctl.
--
Tatsuo Ishii

From bouncefilter Fri Nov 26 21:09:38 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA27806
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 21:08:53 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id LAA05645;
Sat, 27 Nov 1999 11:08:52 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id LAA13113;
Sat, 27 Nov 1999 11:08:51 +0900
To: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: pg_ctl
In-Reply-To: Your message of "Fri, 26 Nov 1999 10:38:06 -0500"
<15710.943630686@sss.pgh.pa.us>
References: <15710.943630686@sss.pgh.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991127110851H.t-ishii@sra.co.jp>
Date: Sat, 27 Nov 1999 11:08:51 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 51

From: Tom Lane <tgl@sss.pgh.pa.us>
Subject: Re: pg_ctl
Date: Fri, 26 Nov 1999 10:38:06 -0500

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

Here is the first draft for the spec of postmaster starting/stopping
tool. I have named it as "pg_ctl."
o pg_ctl [-w] start
start up postmaster.

How will pg_ctl know what to start --- where do the database directory,
port number, and path (to locate the postmaster executable) come from?

Very good question. What I'm thinking now is:

the database directory:
1) $PGDATA (as an environmnet variable)
2) hard coded in the pg_ctl script

the path to postmaster:
1) in the command search path
2) hard coded in the pg_ctl script
3) assume that postmaster lives in the same directory where pg_ctl
has been put

It would be nice if it could report,
for example, the number of backends running (and their pids) etc. For
this purpose I propose followings:

(1) Add another protocol STATUS_REQUEST_CODE to libpq/pqcomm.h.

(2) Add code to process the protocol in
postmaster/postmaster.c:readStartupPacket().

Security issues may be a factor here. Do you want just anyone anywhere
on the net to be able to extract the postmaster status? If not, how
shall we restrict it?

I think a resonable restriction would be let anyone on the same
machine that postmaster is running could issue the protocol.

Another idea might be using our host based authentication. What about
having a "virtual database" used only for the status request protocol?
For example, with below setting, any authenticated user on the net
192.168.0.0 could send the protocol. "statusdb" indicates that backend
should treat it in the special way.

host statusdb 192.168.0.0 255.255.255.0 crypt
--
Tatsuo Ishii

From bouncefilter Fri Nov 26 21:50:40 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 VAA35083
for <pgsql-hackers@postgreSQL.org>;
Fri, 26 Nov 1999 21:49:46 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from lorc.wgcr.org ([207.144.78.40])
by www.wgcr.org (8.8.7/8.8.5) with SMTP id VAA00837;
Fri, 26 Nov 1999 21:49:49 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: Little to None
To: Tatsuo Ishii <t-ishii@sra.co.jp>, lamar.owen@wgcr.org
Subject: Re: [HACKERS] Re: pg_ctl
Date: Fri, 26 Nov 1999 21:31:30 -0500
X-Mailer: KMail [version 1.0.28]
Content-Type: text/plain
Cc: pgsql-hackers@postgreSQL.org
References: <99112611085601.00541@lorc.wgcr.org>
<19991127110531L.t-ishii@sra.co.jp>
In-Reply-To: <19991127110531L.t-ishii@sra.co.jp>
MIME-Version: 1.0
Message-Id: <9911262152160A.00541@lorc.wgcr.org>
Content-Transfer-Encoding: 8bit

On Fri, 26 Nov 1999, Tatsuo Ishii wrote:

If so, feel free to get the startup script
from the RedHat RPM set and cannibalize. This pg_ctl command is going to
greatly simplify startup scripts.

Thanks. I know that the script is very convenient since I've been
using the script for a while:-) This is one of the reason why I start
to implemnt pg_ctl.

The script can become spoiling -- it's biggest problem is the need to run it as
root.

Ok, just a few suggestions:

1.) Allow either environment variables or command line switches to specify
PGDATA, PGLIB, postmaster location, port#, etc.
2.) Fallback to builtin defaults if no envvars or switches specified.
3.) Allow a mix of envvars and switches.

The locations needed:
PGDATA
PGLIB
PATH_TO_POSTMASTER
PGPORT
PATH_TO_PID (could need to be /var/run/pgsql for FHS compliance)

For the PID files, maybe use a format of postmaster.PGPORT (ie,
postmaster.5432). The PID files content, of course, needs to just be the
process identifier in ASCII followed by newline.

Also, options for logging could be passed -- maybe provide a switch to pass
options on to postmaster? This may need to wait for subsequent versions --
getting basic functionality first is a good idea.

It would be nice if a status report from postmaster could include the
envvars it was invoked with, the command line invoked with, and the other
things you already mentioned. (subject to security policy, of course).

For subsquent versions (not to complicate an initial version), being able to
run any version backend using the appropriate version libraries would be nice.
This would involve only one more option -- PATH_TO_POSTGRES. This way, I can
fire up an old postmaster (using an old backend) to dump a database, stop it,
and fire up a new postmaster (and backend) to restore.

I like this command.

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

--
Tatsuo Ishii

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

From bouncefilter Sat Nov 27 00:04:00 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 AAA49435
for <pgsql-hackers@postgreSQL.org>;
Sat, 27 Nov 1999 00:00:02 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA17426;
Fri, 26 Nov 1999 23:59:28 -0500 (EST)
To: Tatsuo Ishii <t-ishii@sra.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: pg_ctl
In-reply-to: Your message of Sat, 27 Nov 1999 11:08:51 +0900
<19991127110851H.t-ishii@sra.co.jp>
Date: Fri, 26 Nov 1999 23:59:27 -0500
Message-ID: <17424.943678767@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Security issues may be a factor here. Do you want just anyone anywhere
on the net to be able to extract the postmaster status? If not, how
shall we restrict it?

I think a resonable restriction would be let anyone on the same
machine that postmaster is running could issue the protocol.

Grumble. That's both too restrictive and not restrictive enough.
In an intranet-LAN kind of situation, you'd like to be able to check
the Postgres status without having to log into the specific machine
that's running the postmaster; while if the postmaster is running on
a large multiuser system, the very last thing that you want to do is
grant access to everyone else on the system.

Another idea might be using our host based authentication. What about
having a "virtual database" used only for the status request protocol?

That could be workable. But I think I may have a better idea.

This morning after I sent my previous comments, I was thinking that the
really right way to do it would be to make the status info be a "virtual
table": you log into Postgres in the normal way, and issue a query
against some special table name, and if you've got the required access
rights then you get an answer. The postgres superuser would always get
an answer, of course, and could grant/deny permissions to other users.

See, the advantage of doing it that way is that we build on top of the
existing Postgres access control and permission mechanisms, instead of
inventing a new set of mechanisms on the spur of the moment. Compare
the Linux "/proc filesystem" for accessing system and process status
information --- /proc isn't a normal filesystem in any sense of the
word, but by making it look like one, the Linux folk managed to reuse
a lot of existing, well-tested lookup and permission-check mechanisms.

Offhand I don't see any reason to think that making system status look
like one or more virtual tables would be much harder to implement than
making it available via special-purpose postmaster protocols. It seems
worth looking into, anyway.

If it doesn't work, then your idea is definitely the next thing to try:
recycle the pg_hba mechanisms to control access to a postmaster status
protocol.

regards, tom lane

From bouncefilter Sat Nov 27 01:43:07 1999
Received: from ext16.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 BAA61476
for <pgsql-hackers@postgreSQL.org>;
Sat, 27 Nov 1999 01:42:41 -0500 (EST)
(envelope-from t-ishii@ext16.sra.co.jp)
Received: from ext16.sra.co.jp (t-ishii@localhost [127.0.0.1])
by ext16.sra.co.jp (8.8.8/8.8.8) with ESMTP id PAA00725;
Sat, 27 Nov 1999 15:35:28 +0900
Message-Id: <199911270635.PAA00725@ext16.sra.co.jp>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: pg_ctl
From: Tatsuo Ishii <t-ishii@sra.co.jp>
Reply-To: t-ishii@sra.co.jp
In-reply-to: Your message of Fri, 26 Nov 1999 23:59:27 EST.
<17424.943678767@sss.pgh.pa.us>
Date: Sat, 27 Nov 1999 15:35:28 +0900
Sender: t-ishii@ext16.sra.co.jp

I think a resonable restriction would be let anyone on the same
machine that postmaster is running could issue the protocol.

Grumble. That's both too restrictive and not restrictive enough.
In an intranet-LAN kind of situation, you'd like to be able to check
the Postgres status without having to log into the specific machine
that's running the postmaster; while if the postmaster is running on
a large multiuser system, the very last thing that you want to do is
grant access to everyone else on the system.

Ok, let's regard the functionality to report the status of postmaster
and/or backends be separate from pg_ctl.

Another idea might be using our host based authentication. What about
having a "virtual database" used only for the status request protocol?

That could be workable. But I think I may have a better idea.

This morning after I sent my previous comments, I was thinking that the
really right way to do it would be to make the status info be a "virtual
table": you log into Postgres in the normal way, and issue a query
against some special table name, and if you've got the required access
rights then you get an answer. The postgres superuser would always get
an answer, of course, and could grant/deny permissions to other users.

Oracle already has the concept of "virtual table" and I like the idea
too.

Offhand I don't see any reason to think that making system status look
like one or more virtual tables would be much harder to implement than
making it available via special-purpose postmaster protocols. It seems
worth looking into, anyway.

Tom, I remember you are going to enhance the function manager to allow
functions to return set of rows. If this is possible, it should be
very easy to implement the virtual tables. Is that what is in your
mind?
--
Tatsuo Ishii

From bouncefilter Sat Nov 27 12:11: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 MAA22464
for <pgsql-hackers@postgreSQL.org>;
Sat, 27 Nov 1999 12:10:46 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA18548;
Sat, 27 Nov 1999 12:10:12 -0500 (EST)
To: t-ishii@sra.co.jp
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: pg_ctl
In-reply-to: Your message of Sat, 27 Nov 1999 15:35:28 +0900
<199911270635.PAA00725@ext16.sra.co.jp>
Date: Sat, 27 Nov 1999 12:10:12 -0500
Message-ID: <18546.943722612@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Offhand I don't see any reason to think that making system status look
like one or more virtual tables would be much harder to implement than
making it available via special-purpose postmaster protocols. It seems
worth looking into, anyway.

Tom, I remember you are going to enhance the function manager to allow
functions to return set of rows.

Moi? I don't recall saying any such thing. Jan sounded like he had
some ideas about how to do it, but my ambitions for fmgr don't go
further than cleaning up NULL handling and fixing its portability
problems. I have too many other things to do...

If this is possible, it should be very easy to implement the virtual
tables.

It would indeed provide a nice way of defining virtual tables --- just
make a function that returns the current table contents on-demand.

regards, tom lane

From bouncefilter Sat Nov 27 13:26:15 1999
Received: from onestone.elsinore.klever.net (root@onestone.elsinore.klever.net
[207.175.129.2]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA29627
for <pgsql-hackers@postgreSQL.org>;
Sat, 27 Nov 1999 13:25:48 -0500 (EST)
(envelope-from sbirch@ironmountainsystems.com)
Received: from ironmountainsystems.com (ppp37.kross.klever.net
[209.203.65.37]) by onestone.elsinore.klever.net (8.8.7/8.8.0)
with ESMTP id LAA32604 for <pgsql-hackers@postgreSQL.org>;
Sat, 27 Nov 1999 11:23:20 -0800
Sender: sbirch@onestone.elsinore.klever.net
Message-ID: <38402223.177E45DA@ironmountainsystems.com>
Date: Sat, 27 Nov 1999 10:25:39 -0800
From: Stephen Birch <sbirch@ironmountainsystems.com>
Organization: Iron Mountain Systems, Inc.
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: PostgreSQL-hackers <pgsql-hackers@postgreSQL.org>
Subject: Referential Integrety
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Just curious, is anyone working on referential integrity (foreign keys),
or is it dead?

Steve

From bouncefilter Sat Nov 27 17:10:20 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 RAA75077;
Sat, 27 Nov 1999 17:09:42 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id RAA01781;
Sat, 27 Nov 1999 17:09:49 -0500
Message-ID: <384056A3.E70625A7@wgcr.org>
Date: Sat, 27 Nov 1999 17:09:39 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-ports@postgresql.org
CC: pgsql-announce@postgresql.org, pgsql-hackers@postgresql.org,
lockhart@alumni.caltech.edu
Subject: Bugfix RPM release available for immediate download
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

By popular demand, I have built and released a new RPM set. Here's the
blurb:
-------------
Announcing the PostgreSQL 6.5.3-2 RPM set.

This RPM set is primarily a bugfix RPM set that fixes the following
problems and adds the following features:

* Insecure permissions on /var/lib/pgsql (PGDATA) -- was set for 755,
now is 700;

* Insecure permissions on /usr/lib/pgsql/backup -- was set for 755, now
is 700 -- while this is nowhere near as severe a hole as the one with
PGDATA, nonetheless any local user could access the backup copy of your
PGDATA tree if you upgraded from a previous major version of PostgreSQL.

* The PostgreSQL-HOWTO was mispackaged in the 6.5.3-1 RPM set. The
6.5.3-2 RPM set omits this HOWTO altogether due to inaccuracies and
nonsense in the HOWTO (read it for yourself on linuxdoc.org to see what
I mean);

* By popular demand, two versions of the RPMs are now packaged -- one
with locale support enabled, and one without locale support. The
non-locale RPMs have a 'nl' after the 6.5.3-2. These nl-RPMs improve
performance of the backend under certain circumstances;

* Further improvements to the README.rpm documentation have been made,
thanks to user feedback.
------------------------

http://www.ramifordistat.net/postgres , as always. I expect they will
be up on ftp.postgresql.org in a few days.

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

From bouncefilter Sat Nov 27 22:05: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 WAA08792
for <pgsql-hackers@postgreSQL.org>;
Sat, 27 Nov 1999 22:04:59 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id WAA01966
for <pgsql-hackers@postgreSQL.org>;
Sat, 27 Nov 1999 22:04:24 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: Re: Concurrent VACUUM: first results
In-reply-to: Your message of Tue, 23 Nov 1999 01:41:05 -0500
<5068.943339265@sss.pgh.pa.us>
Date: Sat, 27 Nov 1999 22:04:24 -0500
Message-ID: <1964.943758264@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I have committed the code change to remove pg_vlock locking from VACUUM.
It turns out the problems I was seeing initially were all due to minor
bugs in the lock manager and vacuum itself.

1. You can run concurrent "VACUUM" this way, but concurrent "VACUUM
ANALYZE" blows up. The problem seems to be that "VACUUM ANALYZE"'s
first move is to delete all available rows in pg_statistic.

The real problem was that VACUUM ANALYZE tried to delete those rows
*while it was outside of any transaction*. If there was a concurrent
VACUUM inserting tuples into pg_statistic, the new VACUUM would end up
calling XactLockTableWait() with an invalid XID, which caused a failure
inside lock.c --- and the failure path neglected to release the spinlock
on the lock table. This was compounded by lmgr.c not bothering to check
the return code from LockAcquire(). So the lock apparently succeeded,
and then all the backends would die with "stuck spinlock" next time they
tried to do any lockmanager operations.

I have fixed the simpler aspects of the problem by adding missing
SpinRelease() calls to lock.c, making lmgr.c test for failure, and
altering VACUUM to not do the bogus row deletion. But I suspect that
there is more to this that I don't understand. Why does calling
XactLockTableWait() with an already-committed XID cause the following
code in lock.c to trigger? Is this evidence of a logic bug in lock.c,
or at least of inadequate checks for bogus input?

/*
* Check the xid entry status, in case something in the ipc
* communication doesn't work correctly.
*/
if (!((result->nHolding > 0) && (result->holders[lockmode] > 0)))
{
XID_PRINT_AUX("LockAcquire: INCONSISTENT ", result);
LOCK_PRINT_AUX("LockAcquire: INCONSISTENT ", lock, lockmode);
/* Should we retry ? */
SpinRelease(masterLock); <<<<<<<<<<<< just added by me
return FALSE;
}

3. I tried running VACUUMs in parallel with the regress tests, and saw
a lot of messages like
NOTICE: Rel tenk1: TID 1/31: InsertTransactionInProgress 29737 - can't shrink relation

Hiroshi pointed out that this was probably due to copy.c releasing the
lock prematurely on the table that is the destination of a COPY. With
that fixed, I get many fewer of these messages, and they're all for
system relations --- which is to be expected. Since we don't hold locks
for system relations until xact commit, it's possible for VACUUM to see
uncommitted tuples when it is vacuuming a system relation. So I think
an occasional message like the above is OK as long as it mentions a
system relation.

I have been running multiple concurrent vacuums in parallel with the
regress tests, and things seem to mostly work. Quite a few regress
tests erratically "fail" under this load because they emit results in
different orders than the expected output shows --- not too surprising
if a VACUUM has come by and reordered a table.

I am still seeing occasional glitches; for example, one vacuum failed
with

NOTICE: FlushRelationBuffers(onek, 24): block 40 is referenced (private 0, global 1)
FATAL 1: VACUUM (vc_rpfheap): FlushRelationBuffers returned -2
pqReadData() -- backend closed the channel unexpectedly.

I believe that these errors are not specifically caused by concurrent
vacuums, but are symptoms of locking-related bugs that we still have
to flush out and fix (cf. discussions on pg_hackers around 9/19/99).
So I've gone ahead and committed the change to allow concurrent
vacuums.

regards, tom lane

From bouncefilter Sun Nov 28 11:00:53 1999
Received: from mailer180.compuserve.com (ABD6F9FB.ipt.aol.com
[171.214.249.251]) by hub.org (8.9.3/8.9.3) with SMTP id LAA93328
for <pgsql-hackers@postgresql.org>;
Sun, 28 Nov 1999 11:00:26 -0500 (EST)
(envelope-from hifiber7@compuserve.com)
From: hifiber7@compuserve.com
Message-Id: <199911281600.LAA93328@hub.org>
To: <pgsql-hackers@postgresql.org>
Subject: AD:Family Reunion T Shirts & More
Date: Sun, 28 Nov 1999 07:24:04

Message sent by: Kuppler Graphics, 32 West Main Street, Maple Shade, New Jersey, 08052,
1-800-810-4330. This list will NOT be sold. All addresses
are automatically added to our remove list.

Hello. My name is Bill from Kuppler Graphics. We do screenprinting on T Shirts, Sweatshirts,
Jackets, Hats, Tote Bags and more!

Do you or someone you know have a Family Reunion coming up? Kuppler Graphics would like to
provide you with some great looking T Shirts for your Reunion.

Kuppler Graphics can also provide you with custom T's and promotional items such as imprinted
magnets, keychains, pens, mugs, hats, etc. for your business or any fundraising activity
(church, school, business etc.) We also can provide you with quality embroidery.

We are a family owned company with over 15 years of experience.

All work is done at this location. No middle man. Our prices are great!

Click reply to email us or call 1-800-810-4330 for more info

Bill
Kuppler Graphics

From bouncefilter Sun Nov 28 06:32:50 1999
Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA66553
for <pgsql-general@postgreSQL.org>;
Sun, 28 Nov 1999 06:32:10 -0500 (EST)
(envelope-from jaco@gospelsjop.com)
Received: from gospelsjop.com ([212.83.89.116]) by relay01.chello.nl
(InterMail v4.01.00 201-232-112) with ESMTP
id <19991128113839.QHAV10258.relay01@gospelsjop.com>
for <pgsql-general@postgreSQL.org>; Sun, 28 Nov 1999 12:38:39 +0100
Sender: jaco
Message-ID: <384113FA.F95CBF2C@gospelsjop.com>
Date: Sun, 28 Nov 1999 12:37:30 +0100
From: Jaco de Groot <jaco@gospelsjop.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-22 i486)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: Re: [GENERAL] drop/rename table and transactions
References: <3.0.5.32.19991126090804.008af890@pop.mecomb.po.my>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is it possible to achieve your goals by using things like
"delete * from table1 where id!=stuffIwant" instead of dropping it?

Yes, I think I better use delete statements instead of drop statements
knowing PostgreSQL can't always handle drop/rename statements in
transactions correctly.

Jaco de Groot

From bouncefilter Sun Nov 28 06:39:50 1999
Received: from relay01.chello.nl (smtp.chello.nl [212.83.68.144])
by hub.org (8.9.3/8.9.3) with ESMTP id GAA67473
for <pgsql-general@postgreSQL.org>;
Sun, 28 Nov 1999 06:39:24 -0500 (EST)
(envelope-from jaco@gospelsjop.com)
Received: from gospelsjop.com ([212.83.89.116]) by relay01.chello.nl
(InterMail v4.01.00 201-232-112) with ESMTP
id <19991128114550.QHIO10258.relay01@gospelsjop.com>
for <pgsql-general@postgreSQL.org>; Sun, 28 Nov 1999 12:45:50 +0100
Sender: jaco
Message-ID: <384115AD.E9C8B29F@gospelsjop.com>
Date: Sun, 28 Nov 1999 12:44:45 +0100
From: Jaco de Groot <jaco@gospelsjop.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-22 i486)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-general@postgreSQL.org
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
References: <14945.943599152@sss.pgh.pa.us> <383E0BD9.F00E5C43@mascari.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mike Mascari wrote:

From an otherwise EXTREMELY happy user :-) (full smile...), I see 3

scenarios:

(1) Disallow DDL statements in transactions
(2) Send NOTICE's asking for the user to not trigger the bug until the bugs
can be fixed -or-
(3) Have all DDL statements implicity commit any running transactions.

I think 1 is the best solution as long as there are bugs concerning DDL
statements in transactions. It will prevent people from getting in
trouble. I've been in this trouble for months :-(. I'm using Java
Servlets to connect to PostgreSQL and I'm having DDL statements whitin
transactions wich sometimes cause an error. This error is hard to find
and solve if you don't know PostgreSQL has problems with DDL statements
in transactions. And if the error occures it doesn't simply crash 1
transaction or connection but it crashes all connections wich prevents
my website from running correctly until I've manualy fixed the problem
(mostly restarting PostgreSQL). To prevent others from getting in the
same trouble I'd like to propose that the next release of PosgreSQL
will dissalow DDL statements in transactions and notice the user this
is a feature wich is currently in development.

Jaco de Groot

From bouncefilter Sun Nov 28 10:09:53 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA87325
for <pgsql-hackers@postgresql.org>;
Sun, 28 Nov 1999 10:09:51 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:62190 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sEIKp4696>; Sun, 28 Nov 1999 16:09:41 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11s61r-0001bx-00; Sun, 28 Nov 1999 16:14:19 +0100
Date: Sun, 28 Nov 1999 16:14:19 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [PATCHES] A bag of psql goodies
In-Reply-To: <199911261746.MAA15855@candle.pha.pa.us>
Message-ID: <Pine.LNX.4.20.9911270230250.471-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 1999-11-26, Bruce Momjian mentioned:

Peter, is there a way from pgsql to show if an index is unique? It
would be nice.

Works here:
(I think this was part of the last patch.)

play=> \d baaz
        Table "baaz"
 Attribute | Type |  Extra   
-----------+------+----------
 a         | int4 | not null
Index: baaz_pkey
Rule: baaz_rule

play=> \d baaz_pkey
Index "baaz_pkey"
Attribute | Type
-----------+------
a | int4
unique btree (primary key)

play=> \d bar
Table "bar"
Attribute | Type | Extra
-----------+------+-------
a | int4 |
b | text |
Indices: barindex,
barunique
Constraints: a > 0
b IN ( 'yes' , 'no' )

play=> \d barindex
Index "barindex"
Attribute | Type
-----------+------
a | int4
btree

play=> \d barunique
Index "barunique"
Attribute | Type
-----------+------
a | int4
b | text
unique btree

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

From bouncefilter Sun Nov 28 10:10:53 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA87622
for <hackers@postgresql.org>; Sun, 28 Nov 1999 10:10:31 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:63104 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sEILV4696>; Sun, 28 Nov 1999 16:10:25 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11s62f-0001el-00; Sun, 28 Nov 1999 16:15:09 +0100
Date: Sun, 28 Nov 1999 16:15:09 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: hackers@postgresql.org
Subject: Re: [HACKERS] Development installation fails
In-Reply-To: <10961.943472348@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.20.9911281205410.3881-101000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1065025979-943791938=:3881"
Content-ID: <Pine.LNX.4.20.9911281614240.6101@localhost.localdomain>
Sender: Peter Eisentraut <peter@hub.org>

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

--8323328-1065025979-943791938=:3881
Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Content-ID: <Pine.LNX.4.20.9911281614241.6101@localhost.localdomain>

On 1999-11-24, Tom Lane mentioned:

~/postgres-cur/bin$ ./initdb --pglib=/home/peter/postgres-cur/lib \
--pgdata=/home/peter/postgres-cur/data

You may need to have env variables PGDATA and PGLIB set during initdb
(at least, the install docs recommended that last I looked) and you
definitely need to have /home/peter/postgres-cur/bin in your PATH.

Okay, thanks for the tip. I thought about this for a while and came to the
conclusion, that this is not only the most likely reason for the oft
criticized installation (non-)simplicity, it is also cumbersome and not
acceptable to have to set environment variables (especially PATH) during
installation. This would also mean that I would have to yank the path away
from my production installation.

So I thunk that initdb could very well find out itself where it is located
and then call ${mydir}/postgres explicitly. That solves the path problem.
Secondly, it could also make educated guesses where the PGLIB is at
(namely ${mydir}/../lib, or ${mydir}/../lib/pgsql as in the RPMs). That
solves the other problem.

I included a patch that does exactly that, so now I can do:
$ ./configure --prefix=/any/path/here
$ make
$ make install
$ /any/path/here/bin/initdb -D /some/other/path #(*)
$ /any/path/here/bin/postmaster -D /some/other/path
and I'm up and running. (No PG* env var or special PATH is set.)

I'm not kidding, this is exactly what I did (well, different path names)
and I'm in business. Okay, there are some other glitches with make install
and initdb being very reluctant to creating directories themselves, but
that could be fixed in another round of changes.

So please examine that patch. It was a very quick hack, so it's not very
refined. Let me know if this sounds good, then I'll put the finishing
touches on it.

-Peter

(*) - Notice that I changed the option to -D (formerly -r). This goes more
nicely with the equivalent postmaster option, and also with "_D_at's where
I want my data to be stored" :)

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

--8323328-1065025979-943791938=:3881
Content-Type: APPLICATION/X-GUNZIP; NAME="initdb-simpl.patch.gz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.20.9911281325380.3881@localhost.localdomain>
Content-Description: Initdb patch
Content-Disposition: ATTACHMENT; FILENAME="initdb-simpl.patch.gz"

H4sICJgPQTgAA2luaXRkYi1zaW1wbC5wYXRjaADVWWtz4sYS/cz+ijZLhd2N
eOjFww65hY3WSwUDF/AmW3ECAg1GFZCIJOz13iS//fZoJIHw+AGW7YqKMjCv
7nP69EwP/vDhA+TzheWl++c855ApcYg1IQXXmRTGplUwLdMzxsFb3p2lBrMV
dCYeQBmK1cNi8VAWQaxWq29yuRzcOau/sqBtX4FUAVE8VKqHqsRmfYg/9DvI
FUEpgf8VAF8nZ412/Uyrjca6Syx9QSBTHGH72Xlr0Dz+MtCajVqRDY2aasNh
9Hk4xB5zCr8C5CxIZ6KONPx25M2I9eYAUpuLjZaXQ2TBNkzrEtbDqc2pSQ1R
rOhlSQT8lLvPy+/h43mr1a0PPtVG1zNzMgtaj5vtRrNXGxmmw8aGw2gnvt6i
JcsAg0z11dyD7mmreQw4mPX6YHLfEIvfQXGAD+R7oM/UdsAEk2JldgoY4bk5
Tm83sLCnj8Cwg6n0YasTHGwW5vZEn4tDjyyWc90jYn78h5l37ZUzIdtWw8d3
qZYxt5rHDtH/2GibhgMM2yL40f9OX88Z2BD+QwHmybJaFcSiHOpy++meNuqD
ei09IpOZDRkR/gKXGJB1C7/ncstLQ/f0WqGQHaU5c4+O0NHwyTnvOUPcmTn1
7jGbEdO+KkVREUSxEuryGb38K9fY11Eeu6IkC6JUDulNpfxAbD+L8Z2+h/EM
/MfI35PTi/HIN7JOpI2xkXroiJRvLY0zwHTBsj3Q4UqfmwZEq9EEDtjHTUFU
pJD95EFw9fsMYLgRklVBlKsPRIjF/372xV39FR/DvVoURFV5gPs73OPymrib
XFaVMrot7ql78ppiL0mCWCrtKfa7PH9NhUtKUZAUJYwFOwoOoNvpD057Wn/Y
P+9qvfOAX1wys9XT13q0BBixI8t3NvO/W7MPaznxbzxf/4ScGB2hlFBJVQVJ
rYaE3mN+g6Rk3eCyolYEqSRts8LWvbUsnsQEGD8jyOnrj9hcDO1AIBQWrI41
v6HNsLLMr+CulsRZucSBhX4DtIQ0MX7fCAaSHk+0uoJr05vR7+bUr1e9dGy9
ru16lw5x10vlAd59sVewWLkejHGp8ZyAZ8MEaxKPIKQ5jvZmOu2c29YlE7hU
lgWpXN6Ox73AY5FhBGw3/buI4BbosijIshoqgmU1LRjdwjI02T1FTgp3SJND
XyENF9H2wdbiLxEMPUCzkbHMx2avP+idtyEqVDfF/5846ax8V0qCrBbD4L4a
hkgde2LhxifAFsSHioFJFyV4RRzXtC303i/IClRGhS1Lb3MJPoztEiqmpIZs
rz3aSI6X94zLnVpFT2NlfvLaeKQ6mPG1Mo7rJz9p7Ua9d9rfFgd9UCDvPIKJ
HYrkPeO+rAhyOXYleGVEtzW/OzJu7MoqIq1uxm6tNPrcVtnaxmRJ24afjuvD
fv2s29IiIeKs2VjPT2xrygitFgW5qmwSGjdzt6h3NcdFWUGFVmMK/RUrHoOM
V5fpcHeA774LDoHeyrKw7Dl8SEfwAxS8xbLAjoJ8JpPe4G3HqRAL3R07sFJU
BKUY0+Vz43ik8HbHw4uTIhYFRYxutG+hOfUP95NO9wstTqem43qC3/S5fnJ+
fgZ4/SMOWnRBt4A4ju0I4NpwTbCEnaxWCzblTXi8f/YbaUkbeU4LatbJZqRj
+0f3tP/f1rDTHWxA/REKBrkqWKv5nIFk030nUYnuTDfsaxh0ILuhz+W1kYXz
frN9Cg2t1TxrDrReH7IXF16WWqSZntrPLGWcIlquxnNzQj3wK6Ark1yzokyR
VEGRoyv2q7F6W0ovyu7TzN/LMlfLEuaqVIluqTQTcMpE91ZLIzW27bmQSl2E
PUvdda+NVMojXz2//YC140VsZXnmPKWPXc9ckPdHe+iTqUCuCooiR3fPJP3Z
k1o+b1gpK3I5xlvwoLt+WS6sHRcgG87OHh5Sb0F3A+8FBie14TZ87HXO1jI6
2iv1gs1V+9z5SYN6qwV4WK2VySz4KkkosanGqAFnhVeNIKWxXFVUKRbM5ydp
nzDvTlYyebpFGl9pLCM2lebR6x39uSNF/2xmBF0o3hGkhEGm/k3Ttvxs2StD
A+d7Wn2gQe8cS5uL9LCnDUIAF2mo96HThr7W0k4GdPsLu6DRgWa7P9DqDfTJ
F4eKO49aiYkjKVxPC87T8XHjqFT8ZODsGD9/0npoMB+ChIN/IPs7tZxNpVJr
6dfbDTjJ26YBNRxNroaTOWbHftvD3Vqk72ECl2RBKZV5CZyUz8nmUeA7l/9A
b5v80+FcudEO+xrLi5fOIx8AX2d+FyePSrg/lOMnZlK4ks+j3fBx4xhokpNH
2i/N/qAP74JlI2mGJ4VDrh3TI9AL5Enn4l8m5VCaqFOmV6pcbPRulgTbsmL2
fdKZ5m93YaqVcXuocM/Kl4OVbDKG8LhRLGP9VFZjUZzprmkZ5CtxbxV62OVv
s+uOg6jDc8zLS7yN+31J5yPDwBcs6+NkZAXLnmoxFsrksCWfk7ti5MazIqF8
S7yspIJrdwaPlXFcxK+YnUG8gvSslgW1KPLS8+XxJZumEU5+XHFbqkqPrD79
pbhlmt+DZ8yzHJoBAr6Cg87baaoWZQxp+ZEF6E7Qks/R3SFyo+mrePvsTEXl
XFio/ZLHJR0yN42oltsSfHNzJPnqj31iArZs3f83LgIyiDtxzCWtRtJR/8Re
3mx1wtSxF5DNDLSzbgtJGza0/klvv5+qHjRy2uoc11tPNxH8OKVb+vzmG9lj
IV+8oiSo0na5kHwkn6TkZ4jo/pf7nSO7v6k7Irz7gv8HUtILmcQpAAA=
--8323328-1065025979-943791938=:3881--

From bouncefilter Sun Nov 28 12:44:55 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA06410
for <hackers@postgreSQL.org>; Sun, 28 Nov 1999 12:44:52 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id MAA03232;
Sun, 28 Nov 1999 12:44:15 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Development installation fails
In-reply-to: Your message of Sun, 28 Nov 1999 16:15:09 +0100 (CET)
<Pine.LNX.4.20.9911281205410.3881-101000@localhost.localdomain>
Date: Sun, 28 Nov 1999 12:44:14 -0500
Message-ID: <3230.943811054@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Peter Eisentraut <peter_e@gmx.net> writes:

On 1999-11-24, Tom Lane mentioned:

You may need to have env variables PGDATA and PGLIB set during initdb
(at least, the install docs recommended that last I looked) and you
definitely need to have /home/peter/postgres-cur/bin in your PATH.

Okay, thanks for the tip. I thought about this for a while and came to the
conclusion, that this is not only the most likely reason for the oft
criticized installation (non-)simplicity, it is also cumbersome and not
acceptable to have to set environment variables (especially PATH) during
installation.

I never much cared for it either. If you can get rid of it, great!

So I thunk that initdb could very well find out itself where it is located
and then call ${mydir}/postgres explicitly. That solves the path problem.
Secondly, it could also make educated guesses where the PGLIB is at
(namely ${mydir}/../lib, or ${mydir}/../lib/pgsql as in the RPMs).

Reasonable, though you should provide a command line switch to override
the guess about PGLIB. Possibly initdb should emit a message like
"Assuming --pglib=/foo/bar/baz" if it's not given a switch.

So please examine that patch. It was a very quick hack, so it's not very
refined. Let me know if this sounds good, then I'll put the finishing
touches on it.

I'm not convinced your "which $0" implementation for finding BINDIR is
portable/reliable. On my system, man which says that it determines
aliases and path by reading ~/.cshrc, which has got obvious problems if
I'm not a csh user. My references say that "which" isn't available on
all systems anyway. It'd probably be a good idea to verify that
$BINDIR/postgres exists after you think you have the value.

BTW, seems like doing PATH=$BINDIR:$PATH in the script would be a lot
easier than hacking all the references to programs --- and it covers
the possibility that one of the invoked programs tries to call another.

The other bit of environment state that initdb currently depends on is
USER. This is a big risk factor IMHO, since it won't be right if you
are su'd to the postgres account. Can you add code to verify that it
is set (or set it if not) and that it matches the actual ownership of
the process?

regards, tom lane

From bouncefilter Sun Nov 28 14:44:33 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA21371
for <pgsql-hackers@postgresql.org>;
Sun, 28 Nov 1999 14:43:34 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.16.215]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sun, 28 Nov 1999 13:35:45 -0600
Sender: ed
Message-ID: <3841864F.F4642DC6@austin.rr.com>
Date: Sun, 28 Nov 1999 13:45:19 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: [HACKERS] How to get OID from INSERT in PL/PGSQL?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Is it possible to programmatically retrieve the OID of a just-inserted
record in a PL/PGSQL function? Apparently, it is not currently
possible in psql, but I'm hoping C programming is not required for
this.

If so, can someone please demonstrate how this is done?

If not, can someone in the know definitely state the means by which it
is currently possible to do this?

Why would someone want to do this? Because it is the only way I know
of to definitively retrieve a newly-generated serial value for use as
the primary/foreign key (a *very* common RDBMS practice). Other
suggested approaches to skinning this cat are welcome. If PL/PGSQL
can't do this, it seems rather severely limited in its usefulness for
non-trivial databases. In this post,

http://www.postgresql.org/mhonarc/pgsql-general/1998-07/msg00203.html

Bruce Momjian says its possible for things using libpq "directly" to
retrieve the oid. Does PL/PGSQL use libpq directly?

This question has been asked in one form or another in a number of
posts in pgsql-general and pgsql-sql, but without any definitive
answers. I have experimented, scoured the mailing list archives, the
postgresql PL/pgSQL documentation, and deja.com to no avail, thus my
post here.

So, is it possible with PL/pgSQL? How? Thanks in advance...

Cheers,
Ed

From bouncefilter Sun Nov 28 14:51:33 1999
Received: from mail.enterprise.net (mail.enterprise.net [194.72.192.18])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA22397
for <pgsql-hackers@postgresql.org>;
Sun, 28 Nov 1999 14:51:14 -0500 (EST) (envelope-from olly@lfix.co.uk)
Received: from linda.lfix.co.uk (root@max02-084.enterprise.net
[194.72.195.204])
by mail.enterprise.net (8.8.5/8.8.5) with ESMTP id TAA19699
for <pgsql-hackers@postgresql.org>; Sun, 28 Nov 1999 19:51:03 GMT
Received: from lfix.co.uk (olly@localhost [127.0.0.1])
by linda.lfix.co.uk (8.9.3/8.9.3/Debian 8.9.3-6) with ESMTP id TAA10719
for <pgsql-hackers@postgresql.org>; Sun, 28 Nov 1999 19:50:55 GMT
Message-Id: <199911281950.TAA10719@linda.lfix.co.uk>
X-Authentication-Warning: linda.lfix.co.uk: Host olly@localhost [127.0.0.1]
claimed to be lfix.co.uk
X-Mailer: exmh version 2.1.1 10/15/1999 (debian)
X-URL: http://www.lfix.co.uk/oliver
X-face:
"xUFVDj+ZJtL_IbURmI}!~xAyPC"Mrk=MkAm&tPQnNq(FWxv49R}\>0oI8VM?O2VY+N7@F-
KMLl*!h}B)u@TW|B}6<X<J|}QsVlTi:RA:O7Abc(@D2Y/"J\S,
b1!<&<B/J}b.Ii9@B]H6V!+#sE0Q
_+=`K$5TI|4I0-=Cp%pt~L#QYydO'iBXR~\tT?uftep9n9AF`@SzTwsw6uqJ}pL,
h(cZi}T#PB"#!k
p^e=Z.K~fuw$l?]lUV)?R]U}l; f*~Ol)#fpKR)Yt}XOr6BI\_Jjr0!@GMnpCTnTym4f; c{;
Ms=0{`D Lq9MO6{wj%s-*N"G,g
To: pgsql-hackers@postgresql.org
Subject: UNION not allowed in sub-selects?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 28 Nov 1999 19:50:55 +0000
From: "Oliver Elphick" <olly@lfix.co.uk>

In 6.5.3, it seems that UNION is not allowed inside a sub-select:

bray=> select p.id, p.name, a.town from person* as p, address as a
bray=> where p.id in
bray-> (select id from customer union select id from supplier);
ERROR: parser: parse error at or near "union"

The same applies to EXCEPT and INTERSECT.

Is this a permanent feature, an oversight, or something already on the TODO
list?

--
Vote against SPAM: http://www.politik-digital.de/spam/
========================================
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
========================================
"The earth is the LORD'S, and the fullness thereof; the
world, and they that dwell therein." Psalms 24:1

From bouncefilter Sun Nov 28 15:05:33 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id PAA24408
for <pgsql-hackers@postgreSQL.org>;
Sun, 28 Nov 1999 15:05:24 -0500 (EST)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id PAA21821;
Sun, 28 Nov 1999 15:03:42 -0500 (EST)
Message-ID: <38418A71.10CFDFE2@southeast.net>
Date: Sun, 28 Nov 1999 15:02:57 -0500
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Lamar Owen <lamar.owen@wgcr.org>
CC: Tatsuo Ishii <t-ishii@sra.co.jp>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: pg_ctl
References: <99112611085601.00541@lorc.wgcr.org>
<19991127110531L.t-ishii@sra.co.jp>
<9911262152160A.00541@lorc.wgcr.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I have a logging subsystem running - just waiting for some aid on an OS-related
bug - but it supports processing an arbitrarily complex options file (both log and
non-log options) and display/logging of the environment options and other
parameters of interest.

regards,

Tim Holloway

Lamar Owen wrote:

On Fri, 26 Nov 1999, Tatsuo Ishii wrote:

If so, feel free to get the startup script
from the RedHat RPM set and cannibalize. This pg_ctl command is going to
greatly simplify startup scripts.

Thanks. I know that the script is very convenient since I've been
using the script for a while:-) This is one of the reason why I start
to implemnt pg_ctl.

The script can become spoiling -- it's biggest problem is the need to run it as
root.

Ok, just a few suggestions:

1.) Allow either environment variables or command line switches to specify
PGDATA, PGLIB, postmaster location, port#, etc.
2.) Fallback to builtin defaults if no envvars or switches specified.
3.) Allow a mix of envvars and switches.

The locations needed:
PGDATA
PGLIB
PATH_TO_POSTMASTER
PGPORT
PATH_TO_PID (could need to be /var/run/pgsql for FHS compliance)

For the PID files, maybe use a format of postmaster.PGPORT (ie,
postmaster.5432). The PID files content, of course, needs to just be the
process identifier in ASCII followed by newline.

Also, options for logging could be passed -- maybe provide a switch to pass
options on to postmaster? This may need to wait for subsequent versions --
getting basic functionality first is a good idea.

It would be nice if a status report from postmaster could include the
envvars it was invoked with, the command line invoked with, and the other
things you already mentioned. (subject to security policy, of course).

For subsquent versions (not to complicate an initial version), being able to
run any version backend using the appropriate version libraries would be nice.
This would involve only one more option -- PATH_TO_POSTGRES. This way, I can
fire up an old postmaster (using an old backend) to dump a database, stop it,
and fire up a new postmaster (and backend) to restore.

I like this command.

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

--
Tatsuo Ishii

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

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

From bouncefilter Sun Nov 28 17:45: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 RAA81421
for <pgsql-hackers@postgreSQL.org>;
Sun, 28 Nov 1999 17:45:00 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id RAA09041;
Sun, 28 Nov 1999 17:43:57 -0500 (EST)
To: "Oliver Elphick" <olly@lfix.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] UNION not allowed in sub-selects?
In-reply-to: Your message of Sun, 28 Nov 1999 19:50:55 +0000
<199911281950.TAA10719@linda.lfix.co.uk>
Date: Sun, 28 Nov 1999 17:43:57 -0500
Message-ID: <9039.943829037@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"Oliver Elphick" <olly@lfix.co.uk> writes:

In 6.5.3, it seems that UNION is not allowed inside a sub-select:
Is this a permanent feature, an oversight, or something already on the TODO
list?

The latter, as a moment's investigation would have shown you:

* Support UNION/INTERSECT/EXCEPT in sub-selects

Changing the grammar to allow it would be the work of a moment,
but the rewriter and other stages need more work. I've been putting
it off until we do the much-discussed, little-implemented querytree
representation redesign. It might be possible to fix this within the
current representation, but Except_Intersect_Rewrite() is so
ugly/grotty/broken that I don't really want to touch it until I can
discard it and rewrite from the ground up...

regards, tom lane

From bouncefilter Sun Nov 28 18:31: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 SAA98897
for <pgsql-hackers@postgreSQL.org>;
Sun, 28 Nov 1999 18:31:03 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id SAA09105;
Sun, 28 Nov 1999 18:30:23 -0500 (EST)
To: Ed Loehr <ELOEHR@austin.rr.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] How to get OID from INSERT in PL/PGSQL?
In-reply-to: Your message of Sun, 28 Nov 1999 13:45:19 -0600
<3841864F.F4642DC6@austin.rr.com>
Date: Sun, 28 Nov 1999 18:30:23 -0500
Message-ID: <9103.943831823@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ed Loehr <ELOEHR@austin.rr.com> writes:

Is it possible to programmatically retrieve the OID of a just-inserted
record in a PL/PGSQL function?

It seems to me that an AFTER INSERT ROW trigger, as well as any kind of
UPDATE or DELETE ROW trigger, ought to have access to the OID of the
row it is fired for. But if it's there in PL/PGSQL, I'm missing it.

I think you could get at the OID from a C-coded trigger procedure, but
I agree that that's more trouble than it's worth.

Why would someone want to do this? Because it is the only way I know
of to definitively retrieve a newly-generated serial value for use as
the primary/foreign key (a *very* common RDBMS practice).

Actually, using OID as a key is deprecated, because dumping and
reloading a DB that contains references to rows by their OIDs is a
risky proposition. I'd suggest using a SERIAL column instead.
SERIAL is basically syntactic sugar for an int4 column with
DEFAULT nextval('associatedSequenceObject')
and this operation generates serial IDs just fine. Or, if you want to
prevent the user from trying to insert a key at random, don't use the
nextval() as a default; instead generate the key value inside the
BEFORE INSERT trigger procedure, overriding whatever the user might
have tried to supply:

new.keycol = select nextval('sequenceObject');
insert into otherTable values(new.keycol, ...);

Anyway, the point is that nextval() is considerably more flexible than
relying solely on the OID sequence generator.

regards, tom lane

From bouncefilter Sun Nov 28 19:30:36 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 TAA04721
for <pgsql-hackers@postgreSQL.org>;
Sun, 28 Nov 1999 19:29:46 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA05309; Mon, 29 Nov 1999 09:28:13 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] Re: Concurrent VACUUM: first results
Date: Mon, 29 Nov 1999 09:32:56 +0900
Message-ID: <001601bf3a01$47d0ae60$2801007e@cadzone.tpf.co.jp>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <1964.943758264@sss.pgh.pa.us>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4

I have committed the code change to remove pg_vlock locking from VACUUM.
It turns out the problems I was seeing initially were all due to minor
bugs in the lock manager and vacuum itself.

1. You can run concurrent "VACUUM" this way, but concurrent "VACUUM
ANALYZE" blows up. The problem seems to be that "VACUUM ANALYZE"'s
first move is to delete all available rows in pg_statistic.

The real problem was that VACUUM ANALYZE tried to delete those rows
*while it was outside of any transaction*. If there was a concurrent
VACUUM inserting tuples into pg_statistic, the new VACUUM would end up
calling XactLockTableWait() with an invalid XID, which caused a failure

Hmm,what I could have seen here was always LockRelation(..,RowExclu
siveLock). But the cause may be same.
We couldn't get xids of not running *transaction*s because its proc->xid
is set to 0(InvalidTransactionId). So blocking transaction couldn' find an
xidLookupEnt in xidTable corresponding to the not running *transaction*
when it tries to LockResolveConflicts() in LockReleaseAll() and couldn't
GrantLock() to XidLookupEnt corresponding to the not running *transac
tion*. After all LockAcquire() from not running *transaction* always fails
once it is blocked.

I have fixed the simpler aspects of the problem by adding missing
SpinRelease() calls to lock.c, making lmgr.c test for failure, and
altering VACUUM to not do the bogus row deletion. But I suspect that
there is more to this that I don't understand. Why does calling
XactLockTableWait() with an already-committed XID cause the following

It's seems strange. Isn't it waiting for a being deleted tuple by vc_upd
stats() in vc_vacone() ?

code in lock.c to trigger? Is this evidence of a logic bug in lock.c,
or at least of inadequate checks for bogus input?

/*
* Check the xid entry status, in case something in the ipc
* communication doesn't work correctly.
*/
if (!((result->nHolding > 0) && (result->holders[lockmode] > 0)))
{
XID_PRINT_AUX("LockAcquire: INCONSISTENT ", result);
LOCK_PRINT_AUX("LockAcquire: INCONSISTENT ", lock, lockmode);
/* Should we retry ? */
SpinRelease(masterLock); <<<<<<<<<<<< just added by me
return FALSE;
}

This is the third time I came here and it was always caused by
other bugs.

Regards,

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Sun Nov 28 22:05:38 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id WAA19873
for <pgsql-hackers@postgreSQL.org>;
Sun, 28 Nov 1999 22:05:24 -0500 (EST) (envelope-from vev@michvhf.com)
Received: (qmail 8925 invoked by uid 1001); 29 Nov 1999 03:05:28 -0000
Date: Sun, 28 Nov 1999 22:05:28 -0500 (EST)
From: Vince Vielhaber <vev@michvhf.com>
To: pgsql-hackers@postgreSQL.org
Subject: Re: BOUNCE pgsql-ports@postgreSQL.org: Non-member submission from
[Joe Brenner <doom@kzsu.stanford.edu>] (fwd)
Message-ID: <Pine.BSF.4.05.9911282204560.8863-100000@paprika.michvhf.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

This one was sent to webmaster for obvious reasons.

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

---------- Forwarded message ----------
Date: Sat, 27 Nov 1999 18:58:57 -0800
From: Joe Brenner <doom@kzsu.stanford.edu>
To: webmaster@PostgreSQL.org
Subject: Re: BOUNCE pgsql-ports@postgreSQL.org: Non-member submission from [Joe
Brenner <doom@kzsu.stanford.edu>]

On http://www.postgresql.org, it says:

RedHat RPMs for v6.5.2 on i386 machines are now available at
ftp://postgresql.org/pub/RPMS/ Please report any questions
or problems to pgsql-ports@postgresql.org.

But when I took the trouble to do this I got a:

BOUNCE pgsql-ports@postgreSQL.org: Non-member submission from [Joe Brenner <doom@kzsu.stanford.edu>]

If anyone really cares, this is the problem I was trying to
report:

Stop me if you've heard this one:

On a RedHat 6.1 box, I've been having trouble getting the
perl DBD-Pg package working, wo I decided to try installing
all of the latest 6.5.3 RPMs you have up on your ftp site.

Afterwards, I still get the same problem though:

rpm -Uhv perl-DBD-Pg-0.91-1.i386.rpm
error: failed dependencies:
libpq.so.1 is needed by perl-DBD-Pg-0.91-1

I gather that libpq.so.1 was once supplied with the
"postgresql-lib" RPM, which has now been split up.

Did someone forget a piece, or is it just that the DBD-Pg
rpm now badly in need of an update?

From bouncefilter Sun Nov 28 23:32:39 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA31292
for <pgsql-hackers@postgreSQL.org>;
Sun, 28 Nov 1999 23:32:25 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA12620
for <pgsql-hackers@postgreSQL.org>;
Sun, 28 Nov 1999 23:31:50 -0500 (EST)
To: pgsql-hackers@postgreSQL.org
Subject: How to get info about deadlocks?
Date: Sun, 28 Nov 1999 23:31:49 -0500
Message-ID: <12617.943849909@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

I've been experimenting with concurrent VACUUMs and getting occasional
instances of

NOTICE: Deadlock detected -- See the lock(l) manual page for a possible cause.
ERROR: WaitOnLock: error on wakeup - Aborting this transaction

It would be really nice if I could find out the particular locks that
are causing this conflict --- but the code that emits these messages
isn't very transparent :-(. Can anyone explain how to determine just
what the deadlock is?

regards, tom lane

From bouncefilter Sun Nov 28 23:50:39 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id XAA33494
for <pgsql-hackers@postgreSQL.org>;
Sun, 28 Nov 1999 23:49:50 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id XAA12730;
Sun, 28 Nov 1999 23:49:15 -0500 (EST)
To: Keith Parks <emkxp01@mtcc.demon.co.uk>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] VACUUM as a denial-of-service attack
In-reply-to: Your message of Tue, 23 Nov 1999 22:18:53 +0000 (GMT)
<199911232218.WAA07783@mtcc.demon.co.uk>
Date: Sun, 28 Nov 1999 23:49:15 -0500
Message-ID: <12728.943850955@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Keith Parks <emkxp01@mtcc.demon.co.uk> writes:

From: Tom Lane <tgl@sss.pgh.pa.us>
I think a reasonable answer to this is to restrict VACUUM on any
table to be allowed only to the table owner and Postgres superuser.
Does anyone have an objection or better idea?

In the dim and distant past I produced a patch that put vacuum
into the list of things that you could GRANT on a per-table
basis. I don't know what effort it would take to rework that
for current or if it would be worth it.

Thanks for the code, but for now I just threw in a quick pg_ownercheck
call: VACUUM will now vacuum all tables if you are the superuser, else
just the tables you own, skipping the rest with a NOTICE. What you had
looked like more infrastructure than I thought the problem was worth...
I suspect most people will run VACUUMs from the superuser account
anyway...

regards, tom lane

From bouncefilter Mon Nov 29 00:04:41 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA35870
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 00:04:35 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA12767;
Mon, 29 Nov 1999 00:03:24 -0500 (EST)
To: Joe Brenner <doom@kzsu.stanford.edu>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: BOUNCE pgsql-ports@postgreSQL.org: Non-member
submission from [Joe Brenner <doom@kzsu.stanford.edu>] (fwd)
In-reply-to: Your message of Sun, 28 Nov 1999 22:05:28 -0500 (EST)
<Pine.BSF.4.05.9911282204560.8863-100000@paprika.michvhf.com>
Date: Mon, 29 Nov 1999 00:03:24 -0500
Message-ID: <12765.943851804@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Joe Brenner <doom@kzsu.stanford.edu> writes:

Stop me if you've heard this one:
rpm -Uhv perl-DBD-Pg-0.91-1.i386.rpm
error: failed dependencies:
libpq.so.1 is needed by perl-DBD-Pg-0.91-1

libpq has been rev 2 (ie, libpq.so.2) since Postgres release 6.4, over
a year ago. It seems your perl module was compiled against a 6.3 or
even older Postgres library. You could try "ln -s libpq.so.2 libpq.so.1"
and see if it works ... but I'd recommend getting a more recent build of
the perl module.

regards, tom lane

From bouncefilter Mon Nov 29 00:15: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 AAA37224
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 00:14:56 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA12795;
Mon, 29 Nov 1999 00:13:10 -0500 (EST)
To: "Hiroshi Inoue" <Inoue@tpf.co.jp>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: Concurrent VACUUM: first results
In-reply-to: Your message of Mon, 29 Nov 1999 09:32:56 +0900
<001601bf3a01$47d0ae60$2801007e@cadzone.tpf.co.jp>
Date: Mon, 29 Nov 1999 00:13:10 -0500
Message-ID: <12793.943852390@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

We couldn't get xids of not running *transaction*s because its proc->xid
is set to 0(InvalidTransactionId). So blocking transaction couldn' find an
xidLookupEnt in xidTable corresponding to the not running *transaction*
when it tries to LockResolveConflicts() in LockReleaseAll() and couldn't
GrantLock() to XidLookupEnt corresponding to the not running *transac
tion*. After all LockAcquire() from not running *transaction* always fails
once it is blocked.

OK, I can believe that ... I assumed that proc->xid still had the ID of
the last transaction, but if it's set to 0 during xact cleanup then this
behavior makes sense. Still, it seems like lock.c should detect the
missing table entry and fail sooner than it does ...

I suspect that
there is more to this that I don't understand. Why does calling
XactLockTableWait() with an already-committed XID cause the following
code in lock.c to trigger? Is this evidence of a logic bug in lock.c,
or at least of inadequate checks for bogus input?

It's seems strange. Isn't it waiting for a being deleted tuple by vc_upd
stats() in vc_vacone() ?

No --- the process that reaches the "INCONSISTENT" exit is the one that
is trying to do the deletion of pg_statistic rows (during VACUUM
startup). Presumably, it's found a row that is stored but not yet
committed by another VACUUM, and is trying to wait for that transaction
to commit.

regards, tom lane

From bouncefilter Mon Nov 29 00:28:55 1999
Received: from candle.pha.pa.us (s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA39586;
Mon, 29 Nov 1999 00:27:46 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA05829;
Mon, 29 Nov 1999 00:13:59 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911290513.AAA05829@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-Reply-To: <199911262030.PAA02358@corvette.mascari.com> from Mike Mascari at
"Nov 26, 1999 03:32:04 pm"
To: Mike Mascari <mascarm@mascari.com>
Date: Mon, 29 Nov 1999 00:13:59 -0500 (EST)
CC: Lamar Owen <lamar.owen@wgcr.org>, Tom Lane <tgl@sss.pgh.pa.us>,
Lincoln Yeoh <lylyeoh@mecomb.com>, pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

if PostgreSQL could successfully rollback DDL statements sanely (and thus
diverge from ORACLE). I guess I don't expect that to happen successfully
until
something the equivalent of TABLESPACES is implemented and there is a
disassociation between table names, index names and their filesystem
counterparts and to be able to "undo" filesystem operations. That, it seems
to
me, will be a major undertaking and not going to happen any time soon...

Ingres has table names that don't match on-disk file names, and it is a
pain to administer because you can't figure out what is going on at the
file system level. Table files have names like AAAHFGE.

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

From bouncefilter Mon Nov 29 00:28: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 AAA39616
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 00:28:42 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
AAA06058;
Mon, 29 Nov 1999 00:20:13 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911290520.AAA06058@candle.pha.pa.us>
Subject: Re: [HACKERS] Re:
In-Reply-To: <19991127110531L.t-ishii@sra.co.jp> from Tatsuo Ishii at "Nov 27,
1999 11:05:31 am"
To: Tatsuo Ishii <t-ishii@sra.co.jp>
Date: Mon, 29 Nov 1999 00:20:13 -0500 (EST)
CC: lamar.owen@wgcr.org, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tatsuo, are you implementing this?

Yes.

If so, feel free to get the startup script
from the RedHat RPM set and cannibalize. This pg_ctl command is going to
greatly simplify startup scripts.

Thanks. I know that the script is very convenient since I've been
using the script for a while:-) This is one of the reason why I start
to implemnt pg_ctl.

Is there a reason it is called pg_ctl and not pg_control? I find I
abbreviate control as ctrl, cntrl, cntl so I usually spell it out.

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

From bouncefilter Mon Nov 29 00:20:46 1999
Received: from mail.austin.rr.com (sm1.texas.rr.com [24.93.35.54])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA38590
for <pgsql-hackers@postgresql.org>;
Mon, 29 Nov 1999 00:20:18 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.16.215]) by mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Sun, 28 Nov 1999 23:20:31 -0600
Sender: ed
Message-ID: <38420D7B.F01F95D4@austin.rr.com>
Date: Sun, 28 Nov 1999 23:22:03 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] How to get OID from INSERT in PL/PGSQL?
References: <9103.943831823@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Why would someone want to do this? Because it is the only way I know
of to definitively retrieve a newly-generated serial value for use as
the primary/foreign key (a *very* common RDBMS practice).

Actually, using OID as a key is deprecated, because dumping and
reloading a DB that contains references to rows by their OIDs is a
risky proposition. I'd suggest using a SERIAL column instead.
SERIAL is basically syntactic sugar for an int4 column with
DEFAULT nextval('associatedSequenceObject')
and this operation generates serial IDs just fine. Or, if you want to
prevent the user from trying to insert a key at random, don't use the
nextval() as a default; instead generate the key value inside the
BEFORE INSERT trigger procedure, overriding whatever the user might
have tried to supply:

new.keycol = select nextval('sequenceObject');
insert into otherTable values(new.keycol, ...);

The scenario I unsuccessfully attempted to communicate is one in which the
OID is used not as a key but rather as the intermediate link to get to the
newly generated SERIAL value, which *is* a primary/foreign key. In other
words, the OID is used to identify the newly-inserted row so that I can
query it to find out the newly generated SERIAL value just after an insert.

newOID = insert into tableWithSerialPrimaryKey(...);
newKey = select serialKey from tableWithSerialPrimaryKey where oid =
newOID;

I'm told I can safely retrieve the last SERIAL value via currval() on the
implicit primary key serial sequence if done within the same "session". In
order to guarantee the same "session", I'm under the impression that I have
to do this either within a PL/pgSQL function for each SERIAL insert, or
maintain persistent client connections between the insert and the select on
the sequence. I think that'll work, even if it is a bit of hassle compared
to a serial insert returning the new serial value.

Thanks,
Ed Loehr

From bouncefilter Mon Nov 29 00:43:50 1999
Received: from trends.net (clio.trends.ca [209.47.148.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA42488
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 00:43:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by trends.net (8.8.8/8.8.8) with ESMTP id AAA09046
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 00:41:48 -0500 (EST)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA12901;
Mon, 29 Nov 1999 00:41:10 -0500 (EST)
To: Ed Loehr <ELOEHR@austin.rr.com>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] How to get OID from INSERT in PL/PGSQL?
In-reply-to: Your message of Sun, 28 Nov 1999 23:22:03 -0600
<38420D7B.F01F95D4@austin.rr.com>
Date: Mon, 29 Nov 1999 00:41:10 -0500
Message-ID: <12899.943854070@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Ed Loehr <ELOEHR@austin.rr.com> writes:

The scenario I unsuccessfully attempted to communicate is one in which the
OID is used not as a key but rather as the intermediate link to get to the
newly generated SERIAL value, which *is* a primary/foreign key. In other
words, the OID is used to identify the newly-inserted row so that I can
query it to find out the newly generated SERIAL value just after an insert.

but ... but ... if you are using a trigger procedure then you can just
read the SERIAL column's value out of the new tuple! Why bother with
a select on OID?

newOID = insert into tableWithSerialPrimaryKey(...);
newKey = select serialKey from tableWithSerialPrimaryKey where oid =
newOID;

If you need to do it like that (ie, not inside a trigger procedure for
tableWithSerialPrimaryKey), consider doing
newKey = nextval('sequenceObjectForTableWithSerialPrimaryKey');
insert into tableWithSerialPrimaryKey(newKey, other-fields);
ie, do the nextval() explicitly and then insert the value, rather than
relying on the default-value expression for the key column.

I'm told I can safely retrieve the last SERIAL value via currval() on
the implicit primary key serial sequence if done within the same
"session".

I don't trust currval a whole lot either... it's OK in simple cases, but
if you have trigger procedures and rules firing all over the place then
you can't always be sure that only one row has gotten inserted... so the
currval might not correspond to the row you were interested in.

nextval() *will* give you a distinct value for each time you call it,
and then you just have to propagate that value to the places it should
go.

regards, tom lane

From bouncefilter Mon Nov 29 00:46:50 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id AAA43065
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 00:45:50 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id OAA01653;
Mon, 29 Nov 1999 14:45:48 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id OAA29478;
Mon, 29 Nov 1999 14:45:47 +0900
To: pgman@candle.pha.pa.us
Cc: lamar.owen@wgcr.org, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re:
In-Reply-To: Your message of "Mon, 29 Nov 1999 00:20:13 -0500 (EST)"
<199911290520.AAA06058@candle.pha.pa.us>
References: <199911290520.AAA06058@candle.pha.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991129144547J.t-ishii@sra.co.jp>
Date: Mon, 29 Nov 1999 14:45:47 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 9

Is there a reason it is called pg_ctl and not pg_control? I find I
abbreviate control as ctrl, cntrl, cntl so I usually spell it out.

I just got the idea from "apachectl" or a famous system call "ioctl."
However, if it's not natural for English speakers, I'm glad to change
it to more appropriate one.
--
Tatsuo Ishii

From bouncefilter Mon Nov 29 01:04:51 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 BAA45617;
Mon, 29 Nov 1999 01:04:23 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id MAA26679;
Mon, 29 Nov 1999 12:59:23 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <3842163A.6AD7B1DE@krs.ru>
Date: Mon, 29 Nov 1999 12:59:22 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Mike Mascari <mascarm@mascari.com>, Lamar Owen <lamar.owen@wgcr.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
References: <199911290513.AAA05829@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

if PostgreSQL could successfully rollback DDL statements sanely (and thus
diverge from ORACLE). I guess I don't expect that to happen successfully
until
something the equivalent of TABLESPACES is implemented and there is a
disassociation between table names, index names and their filesystem
counterparts and to be able to "undo" filesystem operations. That, it seems
to
me, will be a major undertaking and not going to happen any time soon...

Ingres has table names that don't match on-disk file names, and it is a
pain to administer because you can't figure out what is going on at the
file system level. Table files have names like AAAHFGE.

I have to say that I'm going to change on-disk database/table/index
file names to _OID_! This is required by WAL because of inside of
log records there will be just database/table/index oids, not names,
and after crash recovery will not be able to read pg_class to get
database/table/index name using oid ...

Vadim

From bouncefilter Mon Nov 29 01:05:50 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA45931
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 01:05:29 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA07345;
Mon, 29 Nov 1999 01:04:41 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911290604.BAA07345@candle.pha.pa.us>
Subject: Re: [HACKERS] How to get info about deadlocks?
In-Reply-To: <12617.943849909@sss.pgh.pa.us> from Tom Lane at "Nov 28,
1999 11:31:49 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 01:04:41 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I've been experimenting with concurrent VACUUMs and getting occasional
instances of

NOTICE: Deadlock detected -- See the lock(l) manual page for a possible cause.
ERROR: WaitOnLock: error on wakeup - Aborting this transaction

It would be really nice if I could find out the particular locks that
are causing this conflict --- but the code that emits these messages
isn't very transparent :-(. Can anyone explain how to determine just
what the deadlock is?

Massimo has some. See the top of lock.c for pg_options flags to dump
out locks.

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

From bouncefilter Mon Nov 29 01:34:51 1999
Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA49940;
Mon, 29 Nov 1999 01:34:25 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
BAA07430;
Mon, 29 Nov 1999 01:09:41 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911290609.BAA07430@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-Reply-To: <3842163A.6AD7B1DE@krs.ru> from Vadim Mikheev at "Nov 29,
1999 12:59:22 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 29 Nov 1999 01:09:41 -0500 (EST)
CC: Mike Mascari <mascarm@mascari.com>, Lamar Owen <lamar.owen@wgcr.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I have to say that I'm going to change on-disk database/table/index
file names to _OID_! This is required by WAL because of inside of
log records there will be just database/table/index oids, not names,
and after crash recovery will not be able to read pg_class to get
database/table/index name using oid ...

Wow, that is a major pain. Anyone else think so?

Using oid's instead of names may give us some ability to fix some other
bugs, though.

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

From bouncefilter Mon Nov 29 01:18:51 1999
Received: from corvette.mascari.com (dhcp26131045.columbus.rr.com
[24.26.131.45]) by hub.org (8.9.3/8.9.3) with ESMTP id BAA47626;
Mon, 29 Nov 1999 01:18:20 -0500 (EST)
(envelope-from mascarm@mascari.com)
Received: from ferrari (ferrari.mascari.com [192.168.2.1])
by corvette.mascari.com (8.8.7/8.8.7) with ESMTP id BAA19002;
Mon, 29 Nov 1999 01:15:07 -0500
Message-Id: <199911290615.BAA19002@corvette.mascari.com>
From: "Mike Mascari" <mascarm@mascari.com>
To: "Vadim Mikheev" <vadim@krs.ru>, "Bruce Momjian" <pgman@candle.pha.pa.us>
Cc: "Lamar Owen" <lamar.owen@wgcr.org>, "Tom Lane" <tgl@sss.pgh.pa.us>,
"Lincoln Yeoh" <lylyeoh@mecomb.com>, <pgsql-general@postgreSQL.org>,
"PostgreSQL Developers List" <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date: Mon, 29 Nov 1999 01:16:45 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Vadim Mikheev wrote:
Bruce Momjian wrote:

if PostgreSQL could successfully rollback DDL statements sanely (and

thus

diverge from ORACLE). I guess I don't expect that to happen

successfully

until
something the equivalent of TABLESPACES is implemented and there is a
disassociation between table names, index names and their filesystem
counterparts and to be able to "undo" filesystem operations. That, it

seems

to
me, will be a major undertaking and not going to happen any time

soon...

Ingres has table names that don't match on-disk file names, and it is a
pain to administer because you can't figure out what is going on at the
file system level. Table files have names like AAAHFGE.

I have to say that I'm going to change on-disk database/table/index
file names to _OID_! This is required by WAL because of inside of
log records there will be just database/table/index oids, not names,
and after crash recovery will not be able to read pg_class to get
database/table/index name using oid ...

Vadim

Will that aid in fixing a problem such as this:

session 1:

CREATE TABLE example1(value int4);
BEGIN;

session 2:

BEGIN;
ALTER TABLE example1 RENAME TO example2;

session 1:

INSERT INTO example1 VALUES (1);
END;
NOTICE: Abort Transaction and not in in-progress state
ERROR: Cannot write block 0 of example1 [test] blind

session 2:

END;
NOTICE: Abort Transaction and not in in-progress state
ERROR: Cannot write block 0 of example1 [test] blind

Just curious,

Mike (implicit commit) Mascari

From bouncefilter Mon Nov 29 01:32:52 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 BAA49736;
Mon, 29 Nov 1999 01:32:25 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id NAA26907;
Mon, 29 Nov 1999 13:29:07 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <38421D32.90A2E2CB@krs.ru>
Date: Mon, 29 Nov 1999 13:29:06 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Mike Mascari <mascarm@mascari.com>
CC: Bruce Momjian <pgman@candle.pha.pa.us>, Lamar Owen <lamar.owen@wgcr.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
References: <199911290615.BAA19002@corvette.mascari.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mike Mascari wrote:

Will that aid in fixing a problem such as this:

session 1:

CREATE TABLE example1(value int4);
BEGIN;

session 2:

BEGIN;
ALTER TABLE example1 RENAME TO example2;

session 1:

INSERT INTO example1 VALUES (1);
END;
NOTICE: Abort Transaction and not in in-progress state
ERROR: Cannot write block 0 of example1 [test] blind

session 2:

END;
NOTICE: Abort Transaction and not in in-progress state
ERROR: Cannot write block 0 of example1 [test] blind

Seems that oid file names will fix this...
Currently, each shared buffer description structure has
database/table names for the purposes of "blind" writes
(when backend cache hasn't entry for relation and so
bufmgr can't use cache to get names from oids).
ALTER TABLE ... RENAME renames relation file(s) but doesn't
change relation name inside shbuffers...

Mike (implicit commit) Mascari

-:)))

Vadim

From bouncefilter Mon Nov 29 01:43:51 1999
Received: from Mail.austin.rr.com (sm2.texas.rr.com [24.93.35.55])
by hub.org (8.9.3/8.9.3) with ESMTP id BAA51461
for <pgsql-hackers@postgresql.org>;
Mon, 29 Nov 1999 01:43:35 -0500 (EST)
(envelope-from ELOEHR@austin.rr.com)
Received: from austin.rr.com ([24.27.16.215]) by Mail.austin.rr.com with
Microsoft SMTPSVC(5.5.1877.197.19); Mon, 29 Nov 1999 00:35:46 -0600
Sender: ed
Message-ID: <384220FD.E376626C@austin.rr.com>
Date: Mon, 29 Nov 1999 00:45:17 -0600
From: Ed Loehr <ELOEHR@austin.rr.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15smp i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] How to get OID from INSERT in PL/PGSQL?
References: <12899.943854070@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

Ed Loehr <ELOEHR@austin.rr.com> writes:

The scenario I unsuccessfully attempted to communicate is one in which the
OID is used not as a key but rather as the intermediate link to get to the
newly generated SERIAL value, which *is* a primary/foreign key. In other
words, the OID is used to identify the newly-inserted row so that I can
query it to find out the newly generated SERIAL value just after an insert.

but ... but ... if you are using a trigger procedure then you can just
read the SERIAL column's value out of the new tuple! Why bother with
a select on OID?

Because it's not inside a trigger proc, but rather a simple PL/pgSQL function,
so NEW is not available.

newOID = insert into tableWithSerialPrimaryKey(...);
newKey = select serialKey from tableWithSerialPrimaryKey where oid =
newOID;

If you need to do it like that (ie, not inside a trigger procedure for
tableWithSerialPrimaryKey), consider doing
newKey = nextval('sequenceObjectForTableWithSerialPrimaryKey');
insert into tableWithSerialPrimaryKey(newKey, other-fields);
ie, do the nextval() explicitly and then insert the value, rather than
relying on the default-value expression for the key column.

That is what I ended up doing, and it works (not too painful). Thanks.

Cheers,
Ed Loehr

From bouncefilter Mon Nov 29 01:56:51 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 BAA54114;
Mon, 29 Nov 1999 01:56:07 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id NAA27008;
Mon, 29 Nov 1999 13:52:28 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <384222A9.5DE64B@krs.ru>
Date: Mon, 29 Nov 1999 13:52:25 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Mike Mascari <mascarm@mascari.com>, Lamar Owen <lamar.owen@wgcr.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
References: <199911290609.BAA07430@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

I have to say that I'm going to change on-disk database/table/index
file names to _OID_! This is required by WAL because of inside of
log records there will be just database/table/index oids, not names,
and after crash recovery will not be able to read pg_class to get
database/table/index name using oid ...

Wow, that is a major pain. Anyone else think so?

Why it's so painful?
We can write utility to construct database dir with table names
symlinked to real table files -:)
Actually, I don't understand
for what would you need to know what is what, (c) -:)

Using oid's instead of names may give us some ability to fix some other
bugs, though.

Yes.

Vadim

From bouncefilter Mon Nov 29 02:34:52 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 CAA58965;
Mon, 29 Nov 1999 02:34:23 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
CAA12955;
Mon, 29 Nov 1999 02:11:57 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911290711.CAA12955@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-Reply-To: <384222A9.5DE64B@krs.ru> from Vadim Mikheev at "Nov 29,
1999 01:52:25 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 29 Nov 1999 02:11:57 -0500 (EST)
CC: Mike Mascari <mascarm@mascari.com>, Lamar Owen <lamar.owen@wgcr.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

I have to say that I'm going to change on-disk database/table/index
file names to _OID_! This is required by WAL because of inside of
log records there will be just database/table/index oids, not names,
and after crash recovery will not be able to read pg_class to get
database/table/index name using oid ...

Wow, that is a major pain. Anyone else think so?

Why it's so painful?
We can write utility to construct database dir with table names
symlinked to real table files -:)
Actually, I don't understand
for what would you need to know what is what, (c) -:)

With Ingres, you can't just look at a file and know the table name, and
if you need to reload just one file from a tape, it is a royal pain to
know which file to bring back. I have said Ingres make things 100 times
harder for adminstrators by doing this.

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

From bouncefilter Mon Nov 29 02:37:52 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA59420;
Mon, 29 Nov 1999 02:37:45 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id CAA13232;
Mon, 29 Nov 1999 02:33:13 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Vadim Mikheev <vadim@krs.ru>, Mike Mascari <mascarm@mascari.com>,
Lamar Owen <lamar.owen@wgcr.org>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-reply-to: Your message of Mon, 29 Nov 1999 01:09:41 -0500 (EST)
<199911290609.BAA07430@candle.pha.pa.us>
Date: Mon, 29 Nov 1999 02:33:13 -0500
Message-ID: <13230.943860793@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

I have to say that I'm going to change on-disk database/table/index
file names to _OID_! This is required by WAL because of inside of
log records there will be just database/table/index oids, not names,
and after crash recovery will not be able to read pg_class to get
database/table/index name using oid ...

Wow, that is a major pain. Anyone else think so?
Using oid's instead of names may give us some ability to fix some other
bugs, though.

Yes, and yes. I've been trying to nerve myself to propose that, because
it seems the only reasonable way to make rollback of RENAME TABLE and
DROP TABLE work safely. It'll be a pain in the neck for debugging and
admin purposes though.

Can we make some sort of usually-correct-but-not-guaranteed-correct
dump that shows which corresponds to what? Maybe something similar
to the textfile dump of pg_shadow that the postmaster uses for password
authentication? Then at least you'd have some shot at figuring out
which file was what in extremis...

regards, tom lane

From bouncefilter Mon Nov 29 02:59:52 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 CAA63723;
Mon, 29 Nov 1999 02:58:56 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id OAA28203;
Mon, 29 Nov 1999 14:55:17 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <38423163.7EE18BB1@krs.ru>
Date: Mon, 29 Nov 1999 14:55:15 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Mike Mascari <mascarm@mascari.com>, Lamar Owen <lamar.owen@wgcr.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
References: <199911290711.CAA12955@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Bruce Momjian wrote:

Wow, that is a major pain. Anyone else think so?

Why it's so painful?
We can write utility to construct database dir with table names
symlinked to real table files -:)
Actually, I don't understand
for what would you need to know what is what, (c) -:)

With Ingres, you can't just look at a file and know the table name, and
if you need to reload just one file from a tape, it is a royal pain to
know which file to bring back. I have said Ingres make things 100 times
harder for adminstrators by doing this.

Moving table file to/off database dir separately is not right way for
backup/restore...

On-line/off-line full backup utility will copy _all_ database files to
_somewhere_ (tape etc) as well as on-line transaction logs
and pg_control (to know when was the last checkpoint made).
And to restore things after disk failure administrator will
have to copy _all_ files + logs (+logs made as incremental backup)
+ pg_control back and start postmaster.

Vadim

From bouncefilter Mon Nov 29 03:02:58 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 DAA66043;
Mon, 29 Nov 1999 03:02:14 -0500 (EST) (envelope-from vadim@krs.ru)
Received: from krs.ru (dune.krs.ru [195.161.16.38])
by sunpine.krs.ru (8.8.8/8.8.8) with ESMTP id PAA28224;
Mon, 29 Nov 1999 15:00:45 +0700 (KRS)
Sender: root@sunpine.krs.ru
Message-ID: <384232AC.C546A8C0@krs.ru>
Date: Mon, 29 Nov 1999 15:00:44 +0700
From: Vadim Mikheev <vadim@krs.ru>
Organization: OJSC Rostelecom (Krasnoyarsk)
X-Mailer: Mozilla 4.5 [en] (X11; I; FreeBSD 3.0-RELEASE i386)
X-Accept-Language: ru, en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Bruce Momjian <pgman@candle.pha.pa.us>,
Mike Mascari <mascarm@mascari.com>,
Lamar Owen <lamar.owen@wgcr.org>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
References: <13230.943860793@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Tom Lane wrote:

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

I have to say that I'm going to change on-disk database/table/index
file names to _OID_! This is required by WAL because of inside of
log records there will be just database/table/index oids, not names,
and after crash recovery will not be able to read pg_class to get
database/table/index name using oid ...

Wow, that is a major pain. Anyone else think so?
Using oid's instead of names may give us some ability to fix some other
bugs, though.

Yes, and yes. I've been trying to nerve myself to propose that, because
it seems the only reasonable way to make rollback of RENAME TABLE and
DROP TABLE work safely. It'll be a pain in the neck for debugging and
admin purposes though.

So, no more nerves needed, Tom, yeh? -:)
It would be nice if someone else, not me, implement this...

Can we make some sort of usually-correct-but-not-guaranteed-correct
dump that shows which corresponds to what? Maybe something similar
to the textfile dump of pg_shadow that the postmaster uses for password
authentication? Then at least you'd have some shot at figuring out
which file was what in extremis...

As it was proposed - utility to create dir with database name
(in addition to dir with database oid where data really live)
and symlinks there: table_name --> ../db_oid/table_oid

Vadim

From bouncefilter Mon Nov 29 03:13:53 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id DAA69906;
Mon, 29 Nov 1999 03:12:58 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id DAA13367;
Mon, 29 Nov 1999 03:10:35 -0500 (EST)
To: Vadim Mikheev <vadim@krs.ru>
cc: Bruce Momjian <pgman@candle.pha.pa.us>,
Mike Mascari <mascarm@mascari.com>,
Lamar Owen <lamar.owen@wgcr.org>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-reply-to: Your message of Mon, 29 Nov 1999 15:00:44 +0700
<384232AC.C546A8C0@krs.ru>
Date: Mon, 29 Nov 1999 03:10:34 -0500
Message-ID: <13365.943863034@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Vadim Mikheev <vadim@krs.ru> writes:

So, no more nerves needed, Tom, yeh? -:)
It would be nice if someone else, not me, implement this...

Um, I've got more than enough on my plate already...

Can we make some sort of usually-correct-but-not-guaranteed-correct
dump that shows which corresponds to what? Maybe something similar
to the textfile dump of pg_shadow that the postmaster uses for password
authentication? Then at least you'd have some shot at figuring out
which file was what in extremis...

As it was proposed - utility to create dir with database name
(in addition to dir with database oid where data really live)
and symlinks there: table_name --> ../db_oid/table_oid

I saw your message about that after sending mine. Yes, that'd be
a cool way of displaying the relationship. But the main thing to
remember is that it'd only be correct at steady-state when nothing
is being changed. If we tried to guarantee the mapping was correct
100% of the time, we'd be back to square one. Of course, that
makes the whole thing somewhat less useful for debugging purposes,
since Murphy's Law says that the times you really need to know
what's what are just when the system crashed in the middle of
a table rename ;-)

regards, tom lane

From bouncefilter Mon Nov 29 03:19:53 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 DAA71275
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 03:19:33 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id IAA05604;
Mon, 29 Nov 1999 08:21:10 GMT
Sender: lockhart@hub.org
Message-ID: <38423775.2055DF8A@alumni.caltech.edu>
Date: Mon, 29 Nov 1999 08:21: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: Tom Lane <tgl@sss.pgh.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>,
"'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] Getting OID in psql of recent insert
References: <9433.943424941@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'd not object if we removed these operators and instead provided
functions with the standard names log() and exp() for all the
non-integral numeric types. Comments?

I have no great fondness for ";" and ":" as operators, but would like
to see some operators assigned to these functions. Certainly the carat
"^" could work for exp() (or maybe "**" to make those old Fortran
programmers feel better about themselves ;), and perhaps "!^" for
log()? Any other ideas for appropriate symbols for these operators??

- Thomas

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

From bouncefilter Mon Nov 29 04:41:56 1999
Received: from cluster1.vsnl.net.in (cluster1.vsnl.net.in [202.54.1.66])
by hub.org (8.9.3/8.9.3) with ESMTP id EAA82778
for <pgsql-hackers@postgresql.org>;
Mon, 29 Nov 1999 04:40:54 -0500 (EST)
(envelope-from ssmani@stockholding.com)
Received: from mailserver ([202.54.22.166])
by cluster1.vsnl.net.in (8.8.8/8.8.8) with SMTP id PAA01945
for <pgsql-hackers@postgresql.org>;
Mon, 29 Nov 1999 15:11:55 -0500 (GMT)
Received: by mailserver with XtraMail-SMTP/POP3-Server (v1.2 48210005891) for
<pgsql-hackers@postgresql.org> at Mon, 29 Nov 1999 15:21:36 +0570
Message-ID: <38424A66.3349109E@stockholding.com>
Date: Mon, 29 Nov 1999 15:11:58 +0530
From: S S Mani <ssmani@stockholding.com>
X-Mailer: Mozilla 4.05 [en] (Win95; I)
MIME-Version: 1.0
To: pgsql-hackers@postgresql.org
Subject: Pro*C conversion
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi

Is there any package/ application that will convert Pro*Cs which are
currently
running on Unix & Oracle (Server) to any Windows-based/Client-Based
application like VC++ on Personal Oracle?

Pl. reply ASAP.
Bye & Thanks

S. S. Mani

From bouncefilter Mon Nov 29 07:05:56 1999
Received: from Radha.DoCS.UU.SE (e99re41@Radha.DoCS.UU.SE [130.238.9.99])
by hub.org (8.9.3/8.9.3) with SMTP id HAA06856
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 07:05:07 -0500 (EST)
(envelope-from e99re41@DoCS.UU.SE)
Received: from localhost (e99re41@localhost) by Radha.DoCS.UU.SE
(8.6.12/8.6.12) with SMTP id MAA20819;
Mon, 29 Nov 1999 12:58:23 +0100
X-Authentication-Warning: Radha.DoCS.UU.SE: e99re41 owned process doing -bs
Date: Mon, 29 Nov 1999 12:58:22 +0100 (MET)
From: Peter Eisentraut <e99re41@DoCS.UU.SE>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
cc: Tom Lane <tgl@sss.pgh.pa.us>,
"'PostgreSQL-development'" <pgsql-hackers@postgreSQL.org>
Subject: Re: AW: [HACKERS] Getting OID in psql of recent insert
In-Reply-To: <38423775.2055DF8A@alumni.caltech.edu>
Message-ID: <Pine.GSO.4.02A.9911291251350.19842-100000@Radha.DoCS.UU.SE>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 29 Nov 1999, Thomas Lockhart wrote:

I'd not object if we removed these operators and instead provided
functions with the standard names log() and exp() for all the
non-integral numeric types. Comments?

I have no great fondness for ";" and ":" as operators, but would like
to see some operators assigned to these functions. Certainly the carat
"^" could work for exp() (or maybe "**" to make those old Fortran
programmers feel better about themselves ;), and perhaps "!^" for
log()? Any other ideas for appropriate symbols for these operators??

I wasn't aware of any Obfuscated SQL Contest ...

I personally think that the greatest possible benefit can only be derived
if all of this looks as much as possible like actual mathematical writing.
Thus I could agree with a power operator '^' and perhaps even a unary '^'
exponential operator, although that's already questionable. But by
inventing non-standard operators for every function under the sun, just to
have one, you're not doing anyone (including yourself) a favour.

That's just me though. As you said yourself, good ideas will stand the
test of an extended discussion ;)

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

From bouncefilter Mon Nov 29 08:22:57 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 IAA16450
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 08:22:06 -0500 (EST) (envelope-from wieck@debis.com)
Received: by orion.SAPserv.Hamburg.dsh.de for pgsql-hackers@postgreSQL.org
id m11sQaG-0003kGC; Mon, 29 Nov 99 14:11 MET
Message-Id: <m11sQaG-0003kGC@orion.SAPserv.Hamburg.dsh.de>
From: wieck@debis.com (Jan Wieck)
Subject: Re: [HACKERS] Referential Integrety
To: sbirch@ironmountainsystems.com (Stephen Birch)
Date: Mon, 29 Nov 1999 14:11:12 +0100 (MET)
Cc: pgsql-hackers@postgreSQL.org
Reply-To: wieck@debis.com (Jan Wieck)
In-Reply-To: <38402223.177E45DA@ironmountainsystems.com> from "Stephen Birch"
at Nov 27, 99 10:25:39 am
X-Mailer: ELM [version 2.4 PL25]
Content-Type: text

Just curious, is anyone working on referential integrity (foreign keys),
or is it dead?

Slow, but I'm still working on it.

Some people offered help, but noone picked up a little peace
up to now. Might turn out that I have to do it all myself.

Jan

--

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

From bouncefilter Mon Nov 29 10:02:00 1999
Received: from meryl.csd.uu.se (root@meryl.csd.uu.se [130.238.12.42])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA30406
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 10:01:39 -0500 (EST)
(envelope-from e99re41@csd.uu.se)
Received: from fredholm.csd.uu.se (e99re41@fredholm.csd.uu.se [130.238.15.70])
by meryl.csd.uu.se (8.8.5/8.8.5) with SMTP id PAA05948;
Mon, 29 Nov 1999 15:54:05 +0100 (MET)
Date: Mon, 29 Nov 1999 15:54:04 +0100 (MET)
From: Peter Eisentraut <e99re41@csd.uu.se>
Reply-To: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Development installation fails
In-Reply-To: <3230.943811054@sss.pgh.pa.us>
Message-ID: <Pine.GSO.3.96.991129154103.3705A-100000@fredholm.csd.uu.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 28 Nov 1999, Tom Lane wrote:

I'm not convinced your "which $0" implementation for finding BINDIR is
portable/reliable. On my system, man which says that it determines
aliases and path by reading ~/.cshrc, which has got obvious problems if
I'm not a csh user. My references say that "which" isn't available on
all systems anyway. It'd probably be a good idea to verify that
$BINDIR/postgres exists after you think you have the value.

I did a little "which" survey, it seems you're right. On GNU/Linux systems
"which" is a binary which does the seemingly right thing. Under bash
"which" is also often aliased to "type -path". That led me to believe that
the sh built-in "type" might do, but its output format is rather
unpredicable. On FreeBSD "which" is a Perl script, which seems to work
fine.

On Solaris and SGI the problems you pointed out seem to be present, as
"which" is actually implemented as a csh script. However, on the
particular systems I surveyed, the sysadmins were smart enough to provide
working versions (either the GNU or the FreeBSD variant).

To make a long story short, using the implementation I suggested with the
checks you suggested would probably benefit 90% of our users.

BTW, seems like doing PATH=$BINDIR:$PATH in the script would be a lot
easier than hacking all the references to programs --- and it covers
the possibility that one of the invoked programs tries to call another.

I'm really hesitant to changing the path, even if only temporarily. Will
ponder.

The other bit of environment state that initdb currently depends on is
USER. This is a big risk factor IMHO, since it won't be right if you
are su'd to the postgres account. Can you add code to verify that it
is set (or set it if not) and that it matches the actual ownership of
the process?

Yes, I noticed that too. Again, I really don't think that the script
should set USER. If the user chose to unset it, they might have had a
reason for it. The same happened in the createdb, etc. scripts and in
those cases there wasn't even a point for knowing the user at all, AFAI
recall.

Seems like cleaning out the logic of initdb in general is a good idea, so
I'll work on that.

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

From bouncefilter Mon Nov 29 10:40:02 1999
Received: from ra.sai.msu.su ([158.250.29.2])
by hub.org (8.9.3/8.9.3) with ESMTP id KAA35998;
Mon, 29 Nov 1999 10:38:56 -0500 (EST) (envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id SAA21652;
Mon, 29 Nov 1999 18:04:54 +0300 (MSK)
Date: Mon, 29 Nov 1999 18:04:54 +0300 (MSK)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: Marcin Mazurek - Multinet SA - Poznan <m.mazurek@multinet.pl>
cc: pgsql-admin@postgreSQL.org, pgsql-hackers@postgreSQL.org
Subject: Re: [ADMIN] When postgres will be faster?
In-Reply-To: <Pine.BSF.3.96.991129142544.14732L-100000@arka>
Message-ID: <Pine.GSO.3.96.SK.991129174302.27572N-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I'm not concern very much about speed of Postgres but mostly
about its connection schema. Every new connect to database postgres
forks another children. It's impossible to work with different
databases. On my production site I work with persistent connections
between http (mod_perl) <-> postgres and quite satisfies with efficiency -
I have 20 httpd running and 20 db backends accordingly.
This requires some memory, but I could live. Now other developers
want to use postgres as a db backend in their Web applications and
also want to have persistence to some another databases.
If you have N databases and M httpd servers, you will end with
N*M DB backends. This is too much and I'm afraid my solution
could be scalable. MySQL seems could works with several databases.
I don't know if it's possible to have a pool of db childrens,
which connected to, say, template1 database and children could
switch to requested database on demand. This would require some
modification of DBD driver of course, but I think it's not hard.
I'm working on very big project with many databases involved,
current traffic is more than 2 mln. pageviews and most of them
dynamic. We expect about 5x more requests and I really need scalable
solution. Is anybody working on COBRA interface to postgres ?
CORBA is just a magic word for me :-) Could it be a magic wand ?

Regards,

Oleg

On Mon, 29 Nov 1999, Marcin Mazurek - Multinet SA - Poznan wrote:

Date: Mon, 29 Nov 1999 14:27:55 +0100 (CET)
From: Marcin Mazurek - Multinet SA - Poznan <m.mazurek@multinet.pl>
Cc: pgsql-admin@postgreSQL.org
Subject: Re: [ADMIN] When postgres will be faster?

On Mon, 29 Nov 1999 sk.list@comset.net wrote:

Yes! But I recommend backend pool too. What is it? The postmaster task runs now
backend for each query. Good. But After query backend finished. I recommend to
stay backend running within a some timeout. If the next query occured
the postmaster redirect query to any idle backend or run a new one unless. Then
backend serve some connections it shut down itself, this prevents memory leaks.

Somebody advised me to do such thing with servlets, holding pool of
connections in one srvlet and give them as they are needed, but frankly
speaking i have no idea how to do it. Does anybodyhas such examples with
Connection pools?
mazek

Marcin Mazurek

--
administrator
MULTINET SA o/Poznan
http://www.multinet.pl/

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

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

From bouncefilter Mon Nov 29 11:02:00 1999
Received: from fep132.fep.ru (mail@fep132.fep.ru [195.230.89.88])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA40328;
Mon, 29 Nov 1999 11:01:51 -0500 (EST) (envelope-from phd@phd.russ.ru)
Received: from localhost [127.0.0.1] (phd)
by fep132.fep.ru with esmtp (Exim 2.05 #1 (Debian))
id 11sSjl-00005n-00; Mon, 29 Nov 1999 18:29:09 +0300
Date: Mon, 29 Nov 1999 15:29:09 +0000 (GMT)
From: Oleg Broytmann <phd@phd.russ.ru>
X-Sender: phd@fep132.fep.ru
Reply-To: phd2@earthling.net
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-admin@postgresql.org,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: [HACKERS] Re: [ADMIN] When postgres will be faster?
In-Reply-To: <Pine.GSO.3.96.SK.991129174302.27572N-100000@ra>
Message-ID: <Pine.LNX.4.21.9911291523590.308-100000@fep132.fep.ru>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 29 Nov 1999, Oleg Bartunov wrote:

I'm not concern very much about speed of Postgres but mostly
about its connection schema. Every new connect to database postgres
forks another children. It's impossible to work with different
databases. On my production site I work with persistent connections
between http (mod_perl) <-> postgres and quite satisfies with efficiency -
I have 20 httpd running and 20 db backends accordingly.
This requires some memory, but I could live. Now other developers
want to use postgres as a db backend in their Web applications and
also want to have persistence to some another databases.
If you have N databases and M httpd servers, you will end with
N*M DB backends. This is too much and I'm afraid my solution
could be scalable. MySQL seems could works with several databases.

I use (not for production, though) Zope and Postgres (little non
spectacular demo is here: http://sun.med.ru/cgi-bin/Zope.cgi/phd01)
Zope can maintain a database connection or a pool of database
connections. If there is no activity on a connection within a long period
(few hours) Zope closes the connection and reopens it on next access.

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

From bouncefilter Mon Nov 29 10:46:00 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 KAA37445
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 10:45:45 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id KAA16455;
Mon, 29 Nov 1999 10:44:58 -0500 (EST)
To: Peter Eisentraut <peter_e@gmx.net>
cc: hackers@postgreSQL.org
Subject: Re: [HACKERS] Development installation fails
In-reply-to: Your message of Mon, 29 Nov 1999 15:54:04 +0100 (MET)
<Pine.GSO.3.96.991129154103.3705A-100000@fredholm.csd.uu.se>
Date: Mon, 29 Nov 1999 10:44:58 -0500
Message-ID: <16453.943890298@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

On Sun, 28 Nov 1999, Tom Lane wrote:

I'm not convinced your "which $0" implementation for finding BINDIR is
portable/reliable.

To make a long story short, using the implementation I suggested with the
checks you suggested would probably benefit 90% of our users.

And fail entirely for the other 10%? Not good enough if so :-( ... the
idea is to make install easier not harder. How much code would it take
to emulate as much of "which" as we need, do you think? What's our
fallback position if it doesn't work?

The other bit of environment state that initdb currently depends on is
USER.

Yes, I noticed that too. Again, I really don't think that the script
should set USER.

After thinking about it for a while, I think that there shouldn't be any
dependency on USER, period. initdb (and anything else that cares) ought
to get the name of the user they are executing as, and use that. I
can't see any good reason why the name inserted into the databases
should be potentially different from the ownership of the files.

Is 'whoami' a portable way of getting the current user id, or not?
The only reference I have about portable shell programming says that
the POSIX-approved command for this is 'id -u -n', and that 'whoami'
is a BSD-ism. I've got doubts that either one is universal ... we might
have to try both. Grumble.

regards, tom lane

From bouncefilter Mon Nov 29 11:21:01 1999
Received: from localhost (IDENT:root@hectic-3.jpl.nasa.gov [128.149.68.205])
by hub.org (8.9.3/8.9.3) with ESMTP id LAA43021
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 11:20:16 -0500 (EST)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id QAA06157;
Mon, 29 Nov 1999 16:21:52 GMT
Sender: lockhart@hub.org
Message-ID: <3842A820.9E26EA2B@alumni.caltech.edu>
Date: Mon, 29 Nov 1999 16:21: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: Lamar Owen <lamar.owen@wgcr.org>
CC: Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: BOUNCE pgsql-ports@postgreSQL.org: Non-member
submission from[Joe Brenner <doom@kzsu.stanford.edu>] (fwd)
References: <Pine.BSF.4.05.9911282204560.8863-100000@paprika.michvhf.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

On a RedHat 6.1 box, I've been having trouble getting the
perl DBD-Pg package working, wo I decided to try installing
all of the latest 6.5.3 RPMs you have up on your ftp site.
Afterwards, I still get the same problem though:
rpm -Uhv perl-DBD-Pg-0.91-1.i386.rpm
error: failed dependencies:
libpq.so.1 is needed by perl-DBD-Pg-0.91-1
I gather that libpq.so.1 was once supplied with the
"postgresql-lib" RPM, which has now been split up.
Did someone forget a piece, or is it just that the DBD-Pg
rpm now badly in need of an update?

Apparently, perl-DBD-Pg is in need of an update. Didn't the HR6.1 box
come with v6.5.x of Postgres and with DBD-Pg? (I've forgotten...) If
so, DBD-Pg should have been built by RH to be consistant with the
distro so I'm not sure why you are seeing a problem. If it shipped
with some earlier release, then they might be in conflict and we/Lamar
might consider releasing a new version of the perl-DBD-Pg package.

Lamar?

- Thomas

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

From bouncefilter Mon Nov 29 12:01:01 1999
Received: from www.wgcr.org (IDENT:root@www.wgcr.org [206.74.232.194])
by hub.org (8.9.3/8.9.3) with ESMTP id MAA49420
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 12:00:26 -0500 (EST)
(envelope-from lamar.owen@wgcr.org)
Received: from wgcr.org ([206.74.232.197])
by www.wgcr.org (8.8.7/8.8.5) with ESMTP id MAA03451;
Mon, 29 Nov 1999 12:00:06 -0500
Message-ID: <3842B10F.DEB16036@wgcr.org>
Date: Mon, 29 Nov 1999 11:59:59 -0500
From: Lamar Owen <lamar.owen@wgcr.org>
Organization: WGCR Internet Radio
X-Mailer: Mozilla 4.61 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Vince Vielhaber <vev@michvhf.com>, pgsql-hackers@postgreSQL.org,
ianmacd@xs4all.nl
Subject: Re: [HACKERS] perl-DBD-Pg (was Re: BOUNCE pgsql-ports@postgreSQL.org:
Non-member submission from[Joe Brenner <doom@kzsu.stanford.edu>] (fwd))
References: <Pine.BSF.4.05.9911282204560.8863-100000@paprika.michvhf.com>
<3842A820.9E26EA2B@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

[I am cc:'ing Ian MacDonald, the person who packaged perl-DBD]
Thomas Lockhart wrote:

On a RedHat 6.1 box, I've been having trouble getting the
perl DBD-Pg package working, wo I decided to try installing
all of the latest 6.5.3 RPMs you have up on your ftp site.
Afterwards, I still get the same problem though:
rpm -Uhv perl-DBD-Pg-0.91-1.i386.rpm
error: failed dependencies:
libpq.so.1 is needed by perl-DBD-Pg-0.91-1
I gather that libpq.so.1 was once supplied with the
"postgresql-lib" RPM, which has now been split up.
Did someone forget a piece, or is it just that the DBD-Pg
rpm now badly in need of an update?

Apparently, perl-DBD-Pg is in need of an update. Didn't the HR6.1 box
come with v6.5.x of Postgres and with DBD-Pg? (I've forgotten...) If

[snip]

Lamar?

I was afraid you'd ask me that question :-).

perl-DBD is not shipped with RedHat 6.1, according to a browse of my RH
6.1 CD and confirmation through rpmfind.net. According to rpmfind.net,
this rpm is in the libc6 contribs for RedHat, and was last built in
March of 1999. However, due to the dependency on libpq.so.1, it must
have been built prior to the release of RedHat 6.0, which was the first
RedHat release that included libpq.so.2 (as part of PostgreSQL 6.4.2) --
RedHat 5.2 shipped with 6.3.2, which of course included libpq.so.1.
Yes, the RPM's for PostgreSQL were that far out of sync (my primary
motivation for maintaining the RPM's!). (RedHat 6.0's RPM's are dated
April 19, 1999, according to rpmfind.net, which supports my hypothesis).

This RPM needs rebuilding for RedHat 6.1 anyway. The corresponding DBI
rpm will also need to be rebuilt for the same reason -- the perl module
structure changed dramatically from RH 5.x to 6.x.

HTH

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

From bouncefilter Mon Nov 29 13:27:02 1999
Received: from fandango.cs.unitn.it (root@fandango.cs.unitn.it
[193.205.199.228]) by hub.org (8.9.3/8.9.3) with ESMTP id NAA61065
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 13:26:12 -0500 (EST)
(envelope-from dz@cs.unitn.it)
Received: from nikita.dz.net (root@full227.sara.unitn.it [193.205.210.227])
by fandango.cs.unitn.it (8.9.2+3.1W/8.9.3/Debian/GNU) with ESMTP id
TAA27937
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 19:25:48 +0100 (MET)
Received: (from dz@localhost)
by nikita.dz.net (8.9.2+3.1W/8.9.3/Debian/GNU) id SAA01531
for hackers@postgreSQL.org; Mon, 29 Nov 1999 18:47:09 +0100 (MET)
From: Massimo Dal Zotto <dz@cs.unitn.it>
Message-Id: <199911291747.SAA01531@nikita.dz.net>
Subject: Re: [HACKERS] How to get info about deadlocks?
In-Reply-To: <199911290604.BAA07345@candle.pha.pa.us> from Bruce Momjian at
"Nov 29, 1999 1: 4:41 am"
To: hackers@postgreSQL.org (PostgreSQL Hackers)
Date: Mon, 29 Nov 1999 18:47:08 +0100 (MET)
X-Face: #/CK8+4*BjahC~s; 0pC'n?BG2sg|)Lo[ni&26K#Hzqb;
`|ITz461Ozoa^?\=<`UcMuz>SZ~ !(5<H"eq"'z`W0Le%K;
?8TW"8Rg-a9Z~0tN>3]7pv{M8/`<#:}AL|hOX_64_u>N]83dSk-VNBu,~X 5_<+m
X-UIDL: 12257892_192897.483
X-Mailer: ELM [version 2.4ME+ PL48 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I've been experimenting with concurrent VACUUMs and getting occasional
instances of

NOTICE: Deadlock detected -- See the lock(l) manual page for a possible cause.
ERROR: WaitOnLock: error on wakeup - Aborting this transaction

It would be really nice if I could find out the particular locks that
are causing this conflict --- but the code that emits these messages
isn't very transparent :-(. Can anyone explain how to determine just
what the deadlock is?

Massimo has some. See the top of lock.c for pg_options flags to dump
out locks.

Yes, there is a DumpAllLocks() which should dump the lock table in case of
deadlock, but I have never been able to find any useful information from it.
The code is non compiled by default unless you define DEADLOCK_DEBUG.

--
Massimo Dal Zotto

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

From bouncefilter Mon Nov 29 14:15:03 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA66937;
Mon, 29 Nov 1999 14:14:20 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA29881;
Mon, 29 Nov 1999 14:08:41 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911291908.OAA29881@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-Reply-To: <13230.943860793@sss.pgh.pa.us> from Tom Lane at "Nov 29,
1999 02:33:13 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 14:08:41 -0500 (EST)
CC: Vadim Mikheev <vadim@krs.ru>, Mike Mascari <mascarm@mascari.com>,
Lamar Owen <lamar.owen@wgcr.org>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Wow, that is a major pain. Anyone else think so?
Using oid's instead of names may give us some ability to fix some other
bugs, though.

Yes, and yes. I've been trying to nerve myself to propose that, because
it seems the only reasonable way to make rollback of RENAME TABLE and
DROP TABLE work safely. It'll be a pain in the neck for debugging and
admin purposes though.

I look at this and question the value of allowing such fancy things vs.
the ability to look at the directory and know exactly what table is
which file. Maybe we can use file names like 23423_mytable where 24323
is the table oid and mytable is the table name. That way, we can know
the table, and they are unique too to allow RENAME TABLE to work.

This doesn't solve Vadim's problem. His additional work would be to
write a line to the log file for each table create/delete saying I
deleted this table with this oid, and when reading back the log, he has
to record the oid_username combination and use that to translate his log
oids into actual filenames.

In fact, doesn't that information already appear in the WAL log as part
of pg_class changes? Or is the problem that the table changes happen
before the pg_class is committed?

Can we make some sort of usually-correct-but-not-guaranteed-correct
dump that shows which corresponds to what? Maybe something similar
to the textfile dump of pg_shadow that the postmaster uses for password
authentication? Then at least you'd have some shot at figuring out
which file was what in extremis...

That is OK, and a possible workaround if the above idea is not good.

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

From bouncefilter Mon Nov 29 14:17:03 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA67358;
Mon, 29 Nov 1999 14:16:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA29896;
Mon, 29 Nov 1999 14:10:21 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911291910.OAA29896@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-Reply-To: <38423163.7EE18BB1@krs.ru> from Vadim Mikheev at "Nov 29,
1999 02:55:15 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 29 Nov 1999 14:10:20 -0500 (EST)
CC: Mike Mascari <mascarm@mascari.com>, Lamar Owen <lamar.owen@wgcr.org>,
Tom Lane <tgl@sss.pgh.pa.us>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Moving table file to/off database dir separately is not right way for
backup/restore...

On-line/off-line full backup utility will copy _all_ database files to
_somewhere_ (tape etc) as well as on-line transaction logs
and pg_control (to know when was the last checkpoint made).
And to restore things after disk failure administrator will
have to copy _all_ files + logs (+logs made as incremental backup)
+ pg_control back and start postmaster.

No, I am talking about restoring a single table without doing the entire
database. If you recreate the table empty with the same structure,
shutdown db, mv table restored file to data directory and restart, table
not has old contents.

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

From bouncefilter Mon Nov 29 14:18:10 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA67499;
Mon, 29 Nov 1999 14:17:26 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA29912;
Mon, 29 Nov 1999 14:12:04 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911291912.OAA29912@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-Reply-To: <384232AC.C546A8C0@krs.ru> from Vadim Mikheev at "Nov 29,
1999 03:00:44 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 29 Nov 1999 14:12:04 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Mike Mascari <mascarm@mascari.com>,
Lamar Owen <lamar.owen@wgcr.org>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can we make some sort of usually-correct-but-not-guaranteed-correct
dump that shows which corresponds to what? Maybe something similar
to the textfile dump of pg_shadow that the postmaster uses for password
authentication? Then at least you'd have some shot at figuring out
which file was what in extremis...

As it was proposed - utility to create dir with database name
(in addition to dir with database oid where data really live)
and symlinks there: table_name --> ../db_oid/table_oid

That's interesting, but I am concerned about the extra overhead of
creating two links for every file.

The other issue is if the table is accidentally dropped, how do you use
that utility to know the oid of the table that was removed?

I guess I like the OID_tablename idea.

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

From bouncefilter Mon Nov 29 14:18:03 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id OAA67514;
Mon, 29 Nov 1999 14:17:46 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
OAA29927;
Mon, 29 Nov 1999 14:13:36 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911291913.OAA29927@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] drop/rename table and transactions
In-Reply-To: <384232AC.C546A8C0@krs.ru> from Vadim Mikheev at "Nov 29,
1999 03:00:44 pm"
To: Vadim Mikheev <vadim@krs.ru>
Date: Mon, 29 Nov 1999 14:13:36 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Mike Mascari <mascarm@mascari.com>,
Lamar Owen <lamar.owen@wgcr.org>, Lincoln Yeoh <lylyeoh@mecomb.com>,
pgsql-general@postgreSQL.org,
PostgreSQL Developers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

As it was proposed - utility to create dir with database name
(in addition to dir with database oid where data really live)
and symlinks there: table_name --> ../db_oid/table_oid

In fact, let me change what I suggested. Instead of 3434_mytable, I
suggest mytable_3434 so that the tables even appear in alphabetical
order in the directory. The _ may be the wrong character to separate
tablename from oid. Not sure, but we may need to use something that
can't be used in sql like mytable+234.

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

From bouncefilter Mon Nov 29 14:32:03 1999
Received: from tele-post-20.mail.demon.net (tele-post-20.mail.demon.net
[194.217.242.20]) by hub.org (8.9.3/8.9.3) with ESMTP id OAA70035
for <pgsql-hackers@postgresql.org>;
Mon, 29 Nov 1999 14:30:59 -0500 (EST)
(envelope-from emkxp01@mtcc.demon.co.uk)
Received: from mtcc.demon.co.uk ([158.152.183.103])
by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2)
id 11sWVm-0007Rc-0K; Mon, 29 Nov 1999 19:30:58 +0000
Received: from mtcc by mtcc.demon.co.uk (8.9.1b+Sun/SMI-SVR4)
id TAA27498; Mon, 29 Nov 1999 19:30:51 GMT
Message-Id: <199911291930.TAA27498@mtcc.demon.co.uk>
Date: Mon, 29 Nov 1999 19:30:51 +0000 (GMT)
From: Keith Parks <emkxp01@mtcc.demon.co.uk>
Reply-To: Keith Parks <emkxp01@mtcc.demon.co.uk>
Subject: Re: [HACKERS] VACUUM as a denial-of-service attack
To: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgresql.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: JjdSq9MRIU7295xntjZA2w==
X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4m sparc

Tom Lane <tgl@sss.pgh.pa.us>

Keith Parks <emkxp01@mtcc.demon.co.uk> writes:

In the dim and distant past I produced a patch that put vacuum
into the list of things that you could GRANT on a per-table

Thanks for the code, but for now I just threw in a quick pg_ownercheck
call: VACUUM will now vacuum all tables if you are the superuser, else
just the tables you own, skipping the rest with a NOTICE. What you had
looked like more infrastructure than I thought the problem was worth...
I suspect most people will run VACUUMs from the superuser account
anyway...

I didn't think it was worth reworking the code, although I may do
just for fun. Your solution is fine.

Keith.

From bouncefilter Mon Nov 29 15:56:04 1999
Received: from thelab.hub.org (nat196.191.mpoweredpc.net [142.177.196.191])
by hub.org (8.9.3/8.9.3) with ESMTP id PAA81987
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 15:55:14 -0500 (EST) (envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id QAA73695;
Mon, 29 Nov 1999 16:55:14 -0400 (AST) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Mon, 29 Nov 1999 16:55:03 -0400 (AST)
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] VACUUM as a denial-of-service attack
In-Reply-To: <5124.943341039@sss.pgh.pa.us>
Message-ID: <Pine.BSF.4.21.9911291653130.69193-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 23 Nov 1999, Tom Lane wrote:

I think a reasonable answer to this is to restrict VACUUM on any
table to be allowed only to the table owner and Postgres superuser.
Does anyone have an objection or better idea?

To me, this sounds perfectly reasonable and sane...

Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

From bouncefilter Mon Nov 29 17:25:05 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA96340
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 17:24:52 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA15252;
Mon, 29 Nov 1999 17:24:37 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292224.RAA15252@candle.pha.pa.us>
Subject: Re: [HACKERS] Bizarre coding in _bt_binsrch
In-Reply-To: <8552.928629650@sss.pgh.pa.us> from Tom Lane at "Jun 5,
1999 08:40:50 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 17:24:37 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom, I assume you have dealt with this, right?

I have been puzzling out the coding in _bt_binsrch() in
backend/access/nbtree/nbtsearch.c, with an eye to speeding it up for
the many-equal-keys case. I have finally worked out exactly what it's
doing, to wit:

* On a leaf page, we always return the first key >= scan key
* (which could be the last slot + 1).
*
* On a non-leaf page, there are special cases:
*
* For an insertion (srchtype != BT_DESCENT and natts == keysz)
* always return first key >= scan key (which could be off the end).
*
* For a standard search (srchtype == BT_DESCENT and natts == keysz)
* return the first equal key if one exists, else the last lesser key
* if one exists, else the first slot on the page.
*
* For a partial-match search (srchtype == BT_DESCENT and natts < keysz)
* return the last lesser key if one exists, else the first slot.

This strikes me as a tad bizarre --- in particular, the discrepancy
between treatment of equal keys in the normal and partial search cases.

I think I understand why the partial-match code works that way: there
could be matching keys in the sub-page belonging to the last lesser key.
For example, if our scan target is (x = 2) and we have internal keys
(x = 1, y = 2)
(x = 2, y = 1)
then we need to look at the first key's subpages, where we might find
matching keys like (x = 2, y = 0).

The full-width case appears to assume that that can't happen: if we
have a given key in an upper page, there can be *no* equal keys in
subpages to its left. That's a rather strong assumption about how
page splitting is done; is it correct?

Even more to the point, *should* it be correct? If we always returned
the last lesser key, then the code would work for any correctly
sequenced b-tree, but this code looks like it works only if splits occur
only at the leftmost of a group of equal keys. If there are a lot of
equal keys, that could result in a badly unbalanced tree, no? Maybe
that's the real reason why performance seems to be so bad for many
equal keys... maybe the split algorithm needs to be relaxed?

regards, tom lane

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

From bouncefilter Mon Nov 29 17:30:05 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA96845
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 17:29:04 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA15288;
Mon, 29 Nov 1999 17:25:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292225.RAA15288@candle.pha.pa.us>
Subject: Re: [HACKERS] destroydb doesn't close connection with client (httpd
<-> pg)
In-Reply-To: <3762B925.339A6581@bawue.de> from Edmund Mergl at "Jun 12, 1999
09:46:45 pm"
To: Edmund Mergl <E.Mergl@bawue.de>
Date: Mon, 29 Nov 1999 17:25:02 -0500 (EST)
CC: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can someone comment on where we are on this?

[Charset iso-8859-2 unsupported, filtering to ASCII...]

Oleg Bartunov wrote:

I have Web site where I use persistent connection between
httpd (Apache) and database (postgres,6.5). I noticed strange
results I got after reloading page with results from query
when I destroydb , createdb, fill db ( with the same data ).
It seems backend doesn't close connection when db is destroyed
and this produces unpredictable results. My application is
written in Perl and uses DBI/DBD for persistent connection.
I don't know is it DBI/DBD problem or backend must close
all connections to DB when it destroyed.

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

This is not DBI/DBD-Pg specific.

A short test with psql shows, that this seems to be
a bug of postgresql itself.

Create and fill a database. Connect to this database with psql
and perform some query. Without disconnecting destroy and re-create
the database but insert this time different data. Performing
the same query a second time will retrieve the same data as before

Edmund

--
Edmund Mergl mailto:E.Mergl@bawue.de
Im Haldenhau 9 http://www.bawue.de/~mergl
70565 Stuttgart fon: +49 711 747503
Germany

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

From bouncefilter Mon Nov 29 17:30:05 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA96835;
Mon, 29 Nov 1999 17:29:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA15312;
Mon, 29 Nov 1999 17:25:57 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292225.RAA15312@candle.pha.pa.us>
Subject: Re: [PATCHES] Re: [HACKERS] new patches
In-Reply-To: <17191.929220565@sss.pgh.pa.us> from Tom Lane at "Jun 12,
1999 04:49:25 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 17:25:57 -0500 (EST)
CC: Massimo Dal Zotto <dz@cs.unitn.it>,
PostgreSQL Hackers <hackers@postgreSQL.org>,
Pgsql Patches <pgsql-patches@postgreSQL.org>,
Bruce Momjian <maillist@candle.pha.pa.us>, vadim@krs.ru
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Tom, any comment on this?

Massimo Dal Zotto <dz@cs.unitn.it> writes:

Two small patches:
1) make default NBuffers = DEF_MAXBACKENDS*2 as required by check in
PostmasterMain().

I had proposed moving NDBUFS into config.h and fixing the default a few
days ago, but then forgot to do it. As things stand, if you increase
DEF_MAXBACKENDS at configure time, you'll get a postmaster that won't
start unless you give it a -B setting larger than default. This is bad,
and I agree with Massimo that we ought to make sure the default NBuffers
is one that will work with the default MaxBackends.

This patch is not quite right though, since it doesn't account for the
other part of PostmasterMain's condition (NBuffers >= 16). Will fix.

2) check for QueryCancel in the copy command. Maybe we should do the
same in vacuum command (Vadim?).

I'm not too excited about adding QueryCancel support so soon before the
release, but the part of your patch that you didn't mention (diking out
the "file_opened" hack) is really a critical fix --- as the code stood
it would try to fclose() the same stdio file twice, which is disastrous
in most stdio libraries. I applied that part of it... good catch!

regards, tom lane

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

From bouncefilter Mon Nov 29 17:31:05 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA97069
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 17:30:09 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA15325;
Mon, 29 Nov 1999 17:27:30 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292227.RAA15325@candle.pha.pa.us>
Subject: Re: [HACKERS] having bug report
In-Reply-To: <3767ACA4.768CD3C9@sferacarta.com> from "[Jos_] Soares" at "Jun
16, 1999 03:54:44 pm"
To: "[Jos_] Soares" <jose@sferacarta.com>
Date: Mon, 29 Nov 1999 17:27:30 -0500 (EST)
CC: hackers <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Any comments on that status of this one?

* subqueries containing HAVING return incorrect results

select istat from comuni where istat in (
select istat from comuni group by istat having count(istat) > 1
);
ERROR: rewrite: aggregate column of view must be at rigth side in qual

select istat from comuni where istat in (
select istat from comuni group by istat having 1 < count(istat)
);
ERROR: pull_var_clause: Cannot handle node type 108

______________________________________________________________
PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc 2.7.2.3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jose'

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

From bouncefilter Mon Nov 29 17:41:05 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA98842
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 17:40:36 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA15736;
Mon, 29 Nov 1999 17:35:42 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292235.RAA15736@candle.pha.pa.us>
Subject: Re: [HACKERS] Re: [GENERAL] Update of bitmask type
In-Reply-To: <383E32C9.7533ABF2@albourne.com> from Adriaan Joubert at "Nov 26,
1999 09:12:09 am"
To: Adriaan Joubert <a.joubert@albourne.com>
Date: Mon, 29 Nov 1999 17:35:42 -0500 (EST)
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
Postgresql <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=UNKNOWN-8BIT
Content-Transfer-Encoding: 8bit

Bruce Momjian wrote:

I can integrate the type for you into the include/catalog files if
everyone agrees they want it as a standard type and not an contrib type.

Hi,

Attached are the C-routines that implement a BIT and BIT VARYING type.
I know Bruce said he would integrate them, but he is writing a book at
the moment as well, so if somebody can explain to me how to go about
integrating it, or would like to have a go, go ahead.

Applied. I am�embarrassed to say I had a copy from June still in my
mailbox.

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

From bouncefilter Mon Nov 29 17:50:05 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id RAA00397;
Mon, 29 Nov 1999 17:49:42 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA16125;
Mon, 29 Nov 1999 17:46:02 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292246.RAA16125@candle.pha.pa.us>
Subject: Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha
In-Reply-To: <28663.932436912@sss.pgh.pa.us> from Tom Lane at "Jul 19,
1999 10:15:12 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 17:46:02 -0500 (EST)
CC: Uncle George <gatgul@voicenet.com>, Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org, pgsql-ports@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Any ideas on this one?

Uncle George <gatgul@voicenet.com> writes:

In the regression test rules.sql there is this SQL command
update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
Which causes my alpha port to go core.

Yeah. This was reported by Pedro Lobo on 11 June, and we've been
patiently waiting for Jan to decide what to do about it :-(

You could stop the coredump by putting a test into ResolveNew:

{
*nodePtr = copyObject(n);
+ if (IsA(*nodePtr, Var))
((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
}

but what's not so clear is what's supposed to happen when the
replacement item *isn't* a Var.  I tried to convince myself that nothing
needed to happen in that case, but wasn't successful.  (Presumably the
replacement expression contains no instances of the variable being
replaced, so recursing into it with ResolveNew shouldn't be needed
--- but maybe its varlevelsup values need adjusted?)

regards, tom lane

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

From bouncefilter Mon Nov 29 18:02:05 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 SAA03325
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 18:01:17 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
RAA16331;
Mon, 29 Nov 1999 17:57:42 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292257.RAA16331@candle.pha.pa.us>
Subject: Re: [HACKERS] pg_upgrade may be mortally wounded
In-Reply-To: <14739.933689027@sss.pgh.pa.us> from Tom Lane at "Aug 3,
1999 10:03:47 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 17:57:42 -0500 (EST)
CC: Bruce Momjian <maillist@candle.pha.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

New instructions now say that you must stop/restart postmaster after
upgrade. That should fix problem because all index buffers are not
dirty, so stop/start just clears out buffers.

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

BTW, it seems to me that it is a good idea to kill and restart the
postmaster immediately after pg_upgrade finishes. Otherwise there might
be buffers in shared memory that do not reflect the actual contents of
the corresponding pages of the relation files (now that pg_upgrade
overwrote the files with other data).

Your issue with buffer cache is a major one. Clearly, this would be a
problem. However, it is my understanding that the buffer cache after
initdb would only contain system table info, so if they pg_upgrade after
that, there is no way they have bad stuf in the cache, right?

Cached copies of system tables obviously are no problem, since
pg_upgrade doesn't overwrite those. I'm concerned whether there can
be cached copies of pages from user tables or indexes. Since we've
just done a bunch of CREATE INDEXes (and a VACUUM, if my latest hack
is right), it seems at least possible that this would happen.

Now all those user tables will be empty (zero-length files), so there is
nothing to cache. But the user indexes are *not* zero-length --- it looks
like they are at least 2 pages long even when empty. So there seems
to be a real risk of having a cached copy of one of the pages of a user
index while pg_upgrade is overwriting the index file with new data...

regards, tom lane

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

From bouncefilter Mon Nov 29 18:16:06 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA06085
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 18:15:20 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA16911;
Mon, 29 Nov 1999 18:12:36 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292312.SAA16911@candle.pha.pa.us>
Subject: Re: [HACKERS] Bug
In-Reply-To: <Pine.SOL2.3.96.SK.990917143736.19731A-100000@sun.med.ru> from
Oleg Broytmann at "Sep 17, 1999 02:38:45 pm"
To: phd2@earthling.net
Date: Mon, 29 Nov 1999 18:12:36 -0500 (EST)
CC: PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
Artem Chuprina <ran@pirit.com>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

It appears this bug still exists.

---------- Forwarded message ----------
Date: Fri, 17 Sep 1999 17:52:44 +0400 (MSD)
From: Artem Chuprina <ran@pirit.com>

ran=> create table test_source (src text);
CREATE
ran=> insert into test_source values('First distinct');
INSERT 235913 1
ran=> insert into test_source values('First distinct');
INSERT 235914 1
ran=> insert into test_source values('Second distinct');
INSERT 235915 1
ran=> insert into test_source values('Second distinct');
INSERT 235916 1
ran=> select src from test_source;
src
---------------
First distinct
First distinct
Second distinct
Second distinct
(4 rows)

ran=> select distinct src from test_source;
src
---------------
First distinct
Second distinct
(2 rows)

ran=> create sequence seq_test;
CREATE
ran=> create table test1 (n int default nextval('seq_test'), t text);
CREATE
ran=> create table test2 (n int, t text);
CREATE
ran=> insert into test2 ("t") select distinct src from test_source;
INSERT 0 2
ran=> insert into test1 ("t") select distinct src from test_source;
INSERT 0 4

Look here^

ran=> select * from test2;
n|t
-+---------------
|First distinct
|Second distinct
(2 rows)

ran=> select * from test1;
n|t
-+---------------
1|First distinct
2|First distinct
3|Second distinct
4|Second distinct
(4 rows)

PostgreSQL 6.4.2, PostgreSQL 6.5.1.

--
Artem Chuprina E-mail: ran@pirit.com
Network Administrator FIDO: 2:5020/371.32
PIRIT Corp. Phone: +7(095) 115-7101

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

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

From bouncefilter Mon Nov 29 18:20:06 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA06517
for <docs@postgreSQL.org>; Mon, 29 Nov 1999 18:19:16 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA16942;
Mon, 29 Nov 1999 18:16:33 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292316.SAA16942@candle.pha.pa.us>
Subject: Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
In-Reply-To: <Pine.LNX.4.10.9909212031480.1899-200000@peter-e.yi.org> from
Peter Eisentraut at "Sep 21, 1999 11:46:19 pm"
To: Peter Eisentraut <peter_e@gmx.net>
Date: Mon, 29 Nov 1999 18:16:33 -0500 (EST)
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
Vince Vielhaber <vev@michvhf.com>, The Hermit Hacker <scrappy@hub.org>,
docs@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I hope we can get everyone with ideas together before 7.0 is released.

On Sep 20, Bruce Momjian mentioned:

I agree our INSTALL is very large. Is there some way we can simplify
the install process?

On the one hand a database server is probably not your everyday
./configure && make && make install program you get from freshmeat and you
do want to put some time into a proper installation. On the other hand the
INSTALL file is really way too long and makes for unpleasant reading.

Here are a couple of ideas.

* Chapter 2 "Ports" should be moved to the README file (has nothing to do
with the actual installation).

* Move the gory details of item 5 (flex) to a separate file (README.flex).

* Move the locale stuff into a separate file.

* Same with Kerberos

* Move the release notes at the end to CHANGELOG.

That should make the file somewhat smaller, then also it is really to
verbose at times and is formatted really oddly, at least on my system.

Okay, now I really went out of my way and redid the whole thing. You'll
find the result attached. This is merely an idea of what I would consider
simpler. I removed some inconsistencies, things that were unnecessary, too
complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
people can really figure out themselves if they need them in the first
place. And I shrunk the thing to 25%.

Perhaps there should be a separate Install FAQ of the sort "My shell said
'export: Command not found.'" or "What's a shared library?" to move the
really annoying stuff out of people's ways.

Comments?

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

Content-Description: New INSTALL file?

[Attachment, skipping...]

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

From bouncefilter Mon Nov 29 18:28:06 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA08184
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 18:27:59 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA17484;
Mon, 29 Nov 1999 18:27:34 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292327.SAA17484@candle.pha.pa.us>
Subject: Re: [HACKERS] Tricky query, tricky response
In-Reply-To: <37F61E2B.25C8E995@alumni.caltech.edu> from Thomas Lockhart at
"Oct 2, 1999 03:00:59 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Mon, 29 Nov 1999 18:27:34 -0500 (EST)
CC: Peter Eisentraut <peter_e@gmx.net>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

No nested CASE's?

Looks like not. I would guess that it is fairly straightforward to
fix, but am not sure. Tom Lane hunted down an killed most of the CASE
problems (thanks Tom!), and this is in an area he is working on now.
Maybe you can get him to look at it??

Is this an item for the TODO list?

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

From bouncefilter Mon Nov 29 18:29:06 1999
Received: from paprika.michvhf.com (paprika.michvhf.com [209.57.60.12])
by hub.org (8.9.3/8.9.3) with SMTP id SAA08261
for <docs@postgreSQL.org>; Mon, 29 Nov 1999 18:28:42 -0500 (EST)
(envelope-from vev@michvhf.com)
Received: (qmail 11169 invoked by uid 1001); 29 Nov 1999 23:28:46 -0000
Message-ID: <XFMail.991129182846.vev@michvhf.com>
X-Mailer: XFMail 1.4.0 on FreeBSD
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199911292316.SAA16942@candle.pha.pa.us>
Date: Mon, 29 Nov 1999 18:28:46 -0500 (EST)
X-Face: *<Qp5V!eyV,gni`N^N%1YX'$I&uuX]ay;
oq#ZL5Hn8EQsu'.oK0j9$#JM0V?!=Q^[i.81u9
@~=ZjeI}gHY`?2_1,xy/,Gde>0^4Iw)<k8}vg!%l;
&]@PF0LjU)N*m*2"R^UO+PAQ<w}/y)5UVE==w
H$q0*b`HN{+Ekeo?5V(0$MH&NZA3~vOThJxhY(7M:"`CrqO9[VC!^W&&eih!MTq4qk=Vg'd&`{dpgp
3-nck}7do'o/|<RI,
igc#cg8t|PZUEh{Rrx4<~tm`/G8E*wE{G:x}bva@[+YVT`g(u]*^!`1iO*
Sender: vev@paprika.michvhf.com
From: Vince Vielhaber <vev@michvhf.com>
To: Bruce Momjian <pgman@candle.pha.pa.us>
Subject: Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
Cc: Bruce Momjian <maillist@candle.pha.pa.us>,
The Hermit Hacker <scrappy@hub.org>, docs@postgreSQL.org,
Peter Eisentraut <peter_e@gmx.net>

On 29-Nov-99 Bruce Momjian wrote:

I hope we can get everyone with ideas together before 7.0 is released.

It can be greatly simplified but will require changes to configure which
I don't think I can do. I haven't really gotten to know autoconf yet and
I think Peter said he's tied up till after the first of the year but he
still wants to dig into it. Is after the first too late?

Vince.

On Sep 20, Bruce Momjian mentioned:

I agree our INSTALL is very large. Is there some way we can simplify
the install process?

On the one hand a database server is probably not your everyday
./configure && make && make install program you get from freshmeat and you
do want to put some time into a proper installation. On the other hand the
INSTALL file is really way too long and makes for unpleasant reading.

Here are a couple of ideas.

* Chapter 2 "Ports" should be moved to the README file (has nothing to do
with the actual installation).

* Move the gory details of item 5 (flex) to a separate file (README.flex).

* Move the locale stuff into a separate file.

* Same with Kerberos

* Move the release notes at the end to CHANGELOG.

That should make the file somewhat smaller, then also it is really to
verbose at times and is formatted really oddly, at least on my system.

Okay, now I really went out of my way and redid the whole thing. You'll
find the result attached. This is merely an idea of what I would consider
simpler. I removed some inconsistencies, things that were unnecessary, too
complicated, etc. Okay, I removed a lot of stuff, but most of the stuff
people can really figure out themselves if they need them in the first
place. And I shrunk the thing to 25%.

Perhaps there should be a separate Install FAQ of the sort "My shell said
'export: Command not found.'" or "What's a shared library?" to move the
really annoying stuff out of people's ways.

Comments?

--
Peter Eisentraut - peter_e@gmx.net
http://yi.org/peter-e

Content-Description: New INSTALL file?

[Attachment, skipping...]

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

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

From bouncefilter Mon Nov 29 18:40:06 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA09920
for <docs@postgreSQL.org>; Mon, 29 Nov 1999 18:39:05 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
SAA17870;
Mon, 29 Nov 1999 18:38:41 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911292338.SAA17870@candle.pha.pa.us>
Subject: Re: INSTALL file (was Re: [HACKERS] Re: HISTORY for 6.5.2)
In-Reply-To: <XFMail.991129182846.vev@michvhf.com> from Vince Vielhaber at
"Nov
29, 1999 06:28:46 pm"
To: Vince Vielhaber <vev@michvhf.com>
Date: Mon, 29 Nov 1999 18:38:41 -0500 (EST)
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
The Hermit Hacker <scrappy@hub.org>, docs@postgreSQL.org,
Peter Eisentraut <peter_e@gmx.net>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On 29-Nov-99 Bruce Momjian wrote:

I hope we can get everyone with ideas together before 7.0 is released.

It can be greatly simplified but will require changes to configure which
I don't think I can do. I haven't really gotten to know autoconf yet and
I think Peter said he's tied up till after the first of the year but he
still wants to dig into it. Is after the first too late?

No, I don't think so.

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

From bouncefilter Mon Nov 29 19:58:07 1999
Received: from voicenet.com (mail12.voicenet.com [207.103.0.6])
by hub.org (8.9.3/8.9.3) with SMTP id TAA23848
for <pgsql-ports@postgreSQL.org>; Mon, 29 Nov 1999 19:57:21 -0500 (EST)
(envelope-from gatgul@voicenet.com)
Received: (qmail 18938 invoked from network); 30 Nov 1999 00:57:19 -0000
Received: from dialpool1040-pri.voicenet.com (HELO voicenet.com)
(209.71.88.107)
by mail12.voicenet.com with SMTP; 30 Nov 1999 00:57:19 -0000
Sender: gat
Message-ID: <38431247.CE0D5122@voicenet.com>
Date: Mon, 29 Nov 1999 18:54:47 -0500
From: Uncle George <gatgul@voicenet.com>
Organization: Big-Endian
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686)
MIME-Version: 1.0
To: Bruce Momjian <pgman@candle.pha.pa.us>
CC: Tom Lane <tgl@sss.pgh.pa.us>, Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgreSQL.org, pgsql-ports@postgreSQL.org
Subject: Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha
References: <199911292246.RAA16125@candle.pha.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm sorry, the resultant node as returned is not expected. The solution, as
provided, did stop the insidious erasure of a field in a structure it did not own.
I'm content ( but i dont know any better )
If ur asking me what one is suppose to do at this point - I dunno.
gat

Bruce Momjian wrote:

Any ideas on this one?

Uncle George <gatgul@voicenet.com> writes:

In the regression test rules.sql there is this SQL command
update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
Which causes my alpha port to go core.

Yeah. This was reported by Pedro Lobo on 11 June, and we've been
patiently waiting for Jan to decide what to do about it :-(

You could stop the coredump by putting a test into ResolveNew:

{
*nodePtr = copyObject(n);
+ if (IsA(*nodePtr, Var))
((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
}

but what's not so clear is what's supposed to happen when the
replacement item *isn't* a Var.  I tried to convince myself that nothing
needed to happen in that case, but wasn't successful.  (Presumably the
replacement expression contains no instances of the variable being
replaced, so recursing into it with ResolveNew shouldn't be needed
--- but maybe its varlevelsup values need adjusted?)

regards, tom lane

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

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

From bouncefilter Mon Nov 29 19:00:07 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id SAA13179
for <pgsql-hackers@postgresql.org>;
Mon, 29 Nov 1999 18:59:13 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:64462 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sElB224576>; Tue, 30 Nov 1999 00:59:00 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11salq-0000QK-00; Tue, 30 Nov 1999 01:03:50 +0100
Date: Tue, 30 Nov 1999 01:03:50 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Ed Loehr <ELOEHR@austin.rr.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] How to get OID from INSERT in PL/PGSQL?
In-Reply-To: <3841864F.F4642DC6@austin.rr.com>
Message-ID: <Pine.LNX.4.20.9911292245430.658-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 1999-11-28, Ed Loehr mentioned:

Is it possible to programmatically retrieve the OID of a just-inserted
record in a PL/PGSQL function? Apparently, it is not currently
possible in psql, but I'm hoping C programming is not required for
this.

For what it's worth, psql will be able to do this in the next release. It
will look like this:

=> insert into foo values (...);
=> insert into bar values (:LastOid, ...);

which is even marginally SQL compliant as I understand. If you are daring
you can get the current snapshot and try it, but I wouldn't sign my life
away on it quite yet.

Bruce Momjian says its possible for things using libpq "directly" to
retrieve the oid. Does PL/PGSQL use libpq directly?

Everything(?) uses libpq more or less directly. It's just a matter of
interfacing your applicaton to the OidStatus function. The above psql does
just that.

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

From bouncefilter Mon Nov 29 19:01:06 1999
Received: from merganser.its.uu.se (merganser.its.uu.se [130.238.6.236])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA13588
for <hackers@postgresql.org>; Mon, 29 Nov 1999 19:00:23 -0500 (EST)
(envelope-from peter@localhost.its.uu.se)
Received: from regulus.its.uu.se ([130.238.7.19]:61348 "EHLO
regulus.its.uu.se") by merganser.its.uu.se with ESMTP id
<S.sElC924592>; Tue, 30 Nov 1999 01:00:11 +0100
Received: from peter (helo=localhost)
by regulus.its.uu.se with local-esmtp (Exim 3.02 #2)
id 11samy-0000R4-00; Tue, 30 Nov 1999 01:05:00 +0100
Date: Tue, 30 Nov 1999 01:05:00 +0100 (CET)
From: Peter Eisentraut <peter_e@gmx.net>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: hackers@postgresql.org
Subject: Portability (was Re: [HACKERS] Development installation fails)
In-Reply-To: <16453.943890298@sss.pgh.pa.us>
Message-ID: <Pine.LNX.4.20.9911292353510.658-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: Peter Eisentraut <peter@hub.org>

On 1999-11-29, Tom Lane mentioned:

To make a long story short, using the implementation I suggested with the
checks you suggested would probably benefit 90% of our users.

And fail entirely for the other 10%? Not good enough if so :-( ... the
idea is to make install easier not harder. How much code would it take
to emulate as much of "which" as we need, do you think? What's our
fallback position if it doesn't work?

Okay, now you're putting words into my mouth :) The fallback would be not
needing "which" because initdb is called with an explicit path (which is
fairly likely during installation, unless you adjust your path ahead of
time) and also behaviour as it is now (always a good idea).

To reproduce "which" one would need to do some sort of split on PATH,
which would probably require awk and we're trying to avoid that. (And I
don't know awk, but that's just an excuse, no reason.)

After thinking about it for a while, I think that there shouldn't be any
dependency on USER, period. initdb (and anything else that cares) ought
to get the name of the user they are executing as, and use that. I
can't see any good reason why the name inserted into the databases
should be potentially different from the ownership of the files.

One potential goal (which I personally share) of simplifying the
installation process would be to not have to su as postgres but do
everything as root or a user of your choice. Together with Vince's idea of
adding -o and -g options to the install command and a similar option to
initdb, we can do that and it would not be hard to understand from an end
user's point of view. What I don't like is that certain scripts don't find
the USER variable set and then set it themselves. The psql wrapper scripts
do that, but I'm cleaning that up.

Is 'whoami' a portable way of getting the current user id, or not?
The only reference I have about portable shell programming says that
the POSIX-approved command for this is 'id -u -n', and that 'whoami'
is a BSD-ism. I've got doubts that either one is universal ... we might
have to try both. Grumble.

(The psql wrapper scripts use "whoami".)

Once you start wondering in this direction you might soon start noticing
that chances are that shell scripts cannot reliably use *any* external
program. The exceptions might be the handful listed in the GNU makefile
standard, because as we are using autoconf we could assume that they are
present.

We have already taken one step into the direction of providing our own sh
utils collection by way of pg_id (which is also a subset of what "id"
does). We could extend that and provide pg_which and whatever else we need
(of course pg_which will create a chicken and egg problem). But that could
get out of hand and won't help developers either.

One thing I am missing from this project that could really help is a goal
of what sort of operating system it is we are trying to support. In the
beginning the answer was clearly "BSD". Nowadays I believe everyone would
agree that it should be POSIX. In practice it is probably safer to say
POSIX to the extend to which it is supported by the most popular operating
systems.

That doesn't mean others should be locked out, but then *they* should have
to make the adjustments. That means if all reasonable systems have "id"
then the others will have to get a substitute. This also applies to C
source code: If all reasonable systems have CONSTANT defined, then others
will have to define it themselves (possibly assisted via autoconf), but
you should not expect your developers to remember every single constant
you invented yourself because of some obscure conflict. (Yes, I'm also
alluding to PATH_MAX, but it goes further to C functions etc. Recall the
postmaster SSL switch.) But most importantly of all you should not reject
useful extensions because of strange incompatibilities.

We can easily steal the relevant working utilities from some *BSD* code
and provide them as an extra tar ball. "To use PostgreSQL, you need
certain basic 'shell utilility' programs, which you do not seem to have
installed. Please grab the package pgsql-shutils.tar.gz from the
PostgreSQL ftp server. You'll be eternally grateful." Or even include them
in the main tarball, if they aren't too large.

I think the best we could possibly do at this point is to do a survey of
operating systems we support and which are mostly used and see what's
really on there and what POSIX says and then use that as a frame of
reference. Those OS' should probably include *BSD, BSDI, Linux (various
distros), Solaris, SGI, HPUX, Cygwin, (shoot me if I left yours off). I
think the developer circle does have access to all of those. If not, then
it's potentially pointless to *try* to account for them, if we really
can't anyway. This whole portability discussion needs to have a reference.
We can't just always say "I think it's not portable." We need to have a
way to look it up.

Having said that, I'll continue to mess around with initdb on the
assumption that nothing works and we'll see what comes out of it. Thanks
for reading all the way down to here anyway.

-Peter

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

From bouncefilter Mon Nov 29 19:35:08 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 TAA19551
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 19:34:25 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA18425;
Mon, 29 Nov 1999 19:29:05 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300029.TAA18425@candle.pha.pa.us>
Subject: Re: [HACKERS] union and LIMIT problem
In-Reply-To: <Pine.GSO.3.96.SK.991006230035.4801e-100000@ra> from Oleg
Bartunov
at "Oct 6, 1999 11:06:26 pm"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Mon, 29 Nov 1999 19:29:05 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can I assume this is fixed? I see it marked on the TODO list.

Does anybody know how to use UNION and LIMIT together ?
I want to get 10 rows from publications and 10 rows
from keys.

select msg_id from publications limit 10 union
select key_id from keys limit 10
produces
ERROR: parser: parse error at or near "union

select msg_id from publications union
select key_id from keys limit 10
produces something I wasn't expected

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

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

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

From bouncefilter Mon Nov 29 19:32:07 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA19305
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 19:31:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
TAA18561;
Mon, 29 Nov 1999 19:31:20 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300031.TAA18561@candle.pha.pa.us>
Subject: Re: [HACKERS] psql and comments
In-Reply-To: <37FCA084.ADB71A9B@alumni.caltech.edu> from Thomas Lockhart at
"Oct 7, 1999 01:30:44 pm"
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
Date: Mon, 29 Nov 1999 19:31:20 -0500 (EST)
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
Peter Eisentraut <peter_e@gmx.net>,
Postgres Hackers List <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

This is fixed in the current source tree.

The following example shows psql correctly clearing its input buffer
when a line containing *only* a comment is seen, but not completely
clearing the buffer (or not realizing that it is cleared; note the
changed prompt) if the comment is at the end of a valid query.

postgres=> -- comment
postgres=> select 'hi'; -- comment
?column?
--------
hi
(1 row)

postgres->

But aren't they _in_ a new statement, that begins with '--'?

?? Sure, that's what psql thinks. But the first case shown above
should also begin a new statement, changing the prompt (it doesn't,
because after stripping the comment there are zero blanks in the
line). I don't think that is the right behavior though.

Things aren't a big problem the way they stand, but istm that a
completely blank line (after stripping single-line comments) may as
well be the same as an empty line,and that psql could figure that out.

- Thomas

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

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

From bouncefilter Mon Nov 29 19:35:08 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 TAA19541;
Mon, 29 Nov 1999 19:34:16 -0500 (EST) (envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id JAA05979; Tue, 30 Nov 1999 09:29:19 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Vadim Mikheev" <vadim@krs.ru>, "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
"Lamar Owen" <lamar.owen@wgcr.org>,
"Lincoln Yeoh" <lylyeoh@mecomb.com>, <pgsql-general@postgreSQL.org>,
"PostgreSQL Developers List" <hackers@postgreSQL.org>
Subject: RE: [HACKERS] Re: [GENERAL] drop/rename table and transactions
Date: Tue, 30 Nov 1999 09:34:03 +0900
Message-ID: <000201bf3aca$9a3a9ac0$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: <199911291912.OAA29912@candle.pha.pa.us>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Importance: Normal

Hi all,

I propose here that we stop the release of lock before end of transaction.
I have been suffering from the early release of lock.

Comments ?

If we don't allow DDL command inside transaction block,we won't need
the release before end of transaction.
If we allow DDL command inside transaction block,it may be a problem.
But are there any other principles which could guarantee consistency ?

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp

From bouncefilter Mon Nov 29 20:22:08 1999
Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA27170
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 20:21:24 -0500 (EST)
(envelope-from t-ishii@sra.co.jp)
Received: from sranhk.sra.co.jp (sranhk [133.137.36.134])
by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id KAA01155;
Tue, 30 Nov 1999 10:21:22 +0900 (JST)
Received: from localhost (IDENT:t-ishii@localhost [127.0.0.1])
by sranhk.sra.co.jp (8.9.3/3.7W-srambox) with ESMTP id KAA16739;
Tue, 30 Nov 1999 10:21:22 +0900
To: tgl@sss.pgh.pa.us
Cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Re: pg_ctl
In-Reply-To: Your message of "Sat, 27 Nov 1999 12:10:12 -0500"
<18546.943722612@sss.pgh.pa.us>
References: <18546.943722612@sss.pgh.pa.us>
X-Mailer: Mew version 1.93 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991130102122U.t-ishii@sra.co.jp>
Date: Tue, 30 Nov 1999 10:21:22 +0900
From: Tatsuo Ishii <t-ishii@sra.co.jp>
X-Dispatcher: imput version 980905(IM100)
Lines: 21

Tom, I remember you are going to enhance the function manager to allow
functions to return set of rows.

Moi? I don't recall saying any such thing. Jan sounded like he had
some ideas about how to do it, but my ambitions for fmgr don't go
further than cleaning up NULL handling and fixing its portability
problems. I have too many other things to do...

Sorry for the confusion.

If this is possible, it should be very easy to implement the virtual
tables.

It would indeed provide a nice way of defining virtual tables --- just
make a function that returns the current table contents on-demand.

Anyway, it seems you already have an idea how to implement virtual
tables without modifying the fmgr. Can you tell me about that?
--
Tatsuo Ishii

From bouncefilter Mon Nov 29 20:36:08 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA29221;
Mon, 29 Nov 1999 20:35:39 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA20072;
Mon, 29 Nov 1999 20:31:46 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300131.UAA20072@candle.pha.pa.us>
Subject: Re: [DOCS] Re: [HACKERS] Outline for PostgreSQL book
In-Reply-To: <3804410F.A0B29C16@prima.net.id> from Chairudin Sentosa Harjo at
"Oct 13, 1999 03:21:35 pm"
To: chai@prima.net.id
Date: Mon, 29 Nov 1999 20:31:46 -0500 (EST)
CC: Dmitry Samersoff <dms@wplus.net>, Vince Vielhaber <vev@michvhf.com>,
Oliver Elphick <olly@lfix.co.uk>,
PostgreSQL-documentation <docs@postgreSQL.org>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Dmitry Samersoff wrote:

On 13-Oct-99 Vince Vielhaber wrote:

On 13-Oct-99 Bruce Momjian wrote:

2BOOK Authors:
Please, try to keep rights for translating this book into another
languages by you self, not by publisher.

I may ask some St.Pitersburg's publishing company
to make russian translation of this book, but some publishers
like O'Reilly have too hard license policy
and too long reaction time.

I may ask some Indonesian's publishing company to make
Indonesian translation of this book too.
I may help the translation from English to Indonesian language.

Addison-Wesley does a lot of foreign rights sales. Let me know when you
want information.

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

From bouncefilter Mon Nov 29 20:48:14 1999
Received: from mailhub.southeast.net (root@mailhub.southeast.net
[207.98.192.83]) by hub.org (8.9.3/8.9.3) with ESMTP id UAA43604
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 20:47:17 -0500 (EST)
(envelope-from mtsinc@southeast.net)
Received: from southeast.net (mail.mousetech.com [216.199.14.19])
by mailhub.southeast.net (8.8.5/8.8.5) with ESMTP id UAA20728;
Mon, 29 Nov 1999 20:47:08 -0500 (EST)
Message-ID: <38432C76.5D645DD2@southeast.net>
Date: Mon, 29 Nov 1999 20:46:30 -0500
From: Tim Holloway <mtsinc@southeast.net>
X-Mailer: Mozilla 4.7 [en] (Win98; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] How to get info about deadlocks?
References: <12617.943849909@sss.pgh.pa.us>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Well, you have a bit table that indicates what locks are already held and
it's being AND'ed one indicating with the locks you hold. If they overlap,
you're in trouble.

Have you turned on LOCK_MGR_DEBUG? I'd print out the masks if the lock dump
routine doesn't already.

Tom Lane wrote:

I've been experimenting with concurrent VACUUMs and getting occasional
instances of

NOTICE: Deadlock detected -- See the lock(l) manual page for a possible cause.
ERROR: WaitOnLock: error on wakeup - Aborting this transaction

It would be really nice if I could find out the particular locks that
are causing this conflict --- but the code that emits these messages
isn't very transparent :-(. Can anyone explain how to determine just
what the deadlock is?

regards, tom lane

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

From bouncefilter Mon Nov 29 20:53:08 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA46364
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 20:52:09 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA20827;
Mon, 29 Nov 1999 20:49:53 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300149.UAA20827@candle.pha.pa.us>
Subject: Re: indexable and locale
In-Reply-To: <38076E23.DF48EB24@kirra.net> from Goran Thyni at "Oct 15, 1999
08:10:43 pm"
To: Goran Thyni <goran@kirra.net>
Date: Mon, 29 Nov 1999 20:49:52 -0500 (EST)
CC: PostgreSQL-development <hackers@postgreSQL.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Applied.

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Hello again,
I thought I should start making some small contibutions before 7.0.

Attached is a patch to the old problem discussed feverly before 6.5.
What is does:
for locale-enabled servers:
use index if last char before '%' is ascii.
for non-locale servers:
do not use locale if last char is non-ascii since it is wrong anyway.

Comments?

regards,
--
-----------------
G_ran Thyni
On quiet nights you can hear Windows NT reboot!

diff -c pgsql/src/backend/optimizer/path/indxpath.c work/pgsql/src/backend/optimizer/path/indxpath.c
*** pgsql/src/backend/optimizer/path/indxpath.c	Wed Oct  6 18:33:57 1999
--- work/pgsql/src/backend/optimizer/path/indxpath.c	Fri Oct 15 19:54:34 1999
***************
*** 1934,1968 ****
op = makeOper(optup->t_data->t_oid, InvalidOid, BOOLOID, 0, NULL);
expr = make_opclause(op, leftop, (Var *) con);
result = lcons(expr, NIL);
- 
/*
! 	 * In ASCII locale we say "x <= prefix\377".  This does not
! 	 * work for non-ASCII collation orders, and it's not really
! 	 * right even for ASCII.  FIX ME!
! 	 * Note we assume the passed prefix string is workspace with
! 	 * an extra byte, as created by the xxx_fixed_prefix routines above.
*/
! #ifndef USE_LOCALE
! 	prefixlen = strlen(prefix);
! 	prefix[prefixlen] = '\377';
! 	prefix[prefixlen+1] = '\0';
! 
! 	optup = SearchSysCacheTuple(OPRNAME,
! 								PointerGetDatum("<="),
! 								ObjectIdGetDatum(datatype),
! 								ObjectIdGetDatum(datatype),
! 								CharGetDatum('b'));
! 	if (!HeapTupleIsValid(optup))
! 		elog(ERROR, "prefix_quals: no <= operator for type %u", datatype);
! 	conval = (datatype == NAMEOID) ?
! 		(void*) namein(prefix) : (void*) textin(prefix);
! 	con = makeConst(datatype, ((datatype == NAMEOID) ? NAMEDATALEN : -1),
! 					PointerGetDatum(conval),
! 					false, false, false, false);
! 	op = makeOper(optup->t_data->t_oid, InvalidOid, BOOLOID, 0, NULL);
! 	expr = make_opclause(op, leftop, (Var *) con);
! 	result = lappend(result, expr);
! #endif
! 
return result;
}
--- 1934,1970 ----
op = makeOper(optup->t_data->t_oid, InvalidOid, BOOLOID, 0, NULL);
expr = make_opclause(op, leftop, (Var *) con);
result = lcons(expr, NIL);
/*
! 	 * If last is in ascii range make it indexable,
! 	 * else let it be.
! 	 * FIXME: find way to use locate for this to support
! 	 *        indexing of non-ascii characters.
*/
! 	prefixlen = strlen(prefix) - 1;
! 	elog(DEBUG, "XXX1 %s", prefix);
! 	if ((unsigned) prefix[prefixlen] < 126)
! 	  {
! 	    prefix[prefixlen]++;
! 	    elog(DEBUG, "XXX2 %s", prefix);
! 	    optup = SearchSysCacheTuple(OPRNAME,
! 					PointerGetDatum("<="),
! 					ObjectIdGetDatum(datatype),
! 					ObjectIdGetDatum(datatype),
! 					CharGetDatum('b'));
! 	    if (!HeapTupleIsValid(optup))
! 	      elog(ERROR, "prefix_quals: no <= operator for type %u", datatype);
! 	    conval = (datatype == NAMEOID) ?
! 	      (void*) namein(prefix) : (void*) textin(prefix);
! 	    con = makeConst(datatype, ((datatype == NAMEOID) ? NAMEDATALEN : -1),
! 			    PointerGetDatum(conval),
! 			    false, false, false, false);
! 	    op = makeOper(optup->t_data->t_oid, InvalidOid, BOOLOID, 0, NULL);
! 	    expr = make_opclause(op, leftop, (Var *) con);
! 	    result = lappend(result, expr);
! 	  }
return result;
}

[application/x-gzip is not supported, skipping...]

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

From bouncefilter Mon Nov 29 20:52:08 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA46331
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 20:52:00 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA20842;
Mon, 29 Nov 1999 20:51:27 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300151.UAA20842@candle.pha.pa.us>
Subject: Re: [HACKERS] indexable and locale
In-Reply-To: <199910160200.LAA01650@ext16.sra.co.jp> from Tatsuo Ishii at "Oct
16, 1999 11:00:34 am"
To: t-ishii@sra.co.jp
Date: Mon, 29 Nov 1999 20:51:27 -0500 (EST)
CC: Goran Thyni <goran@kirra.net>,
PostgreSQL-development <hackers@postgreSQL.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hello again,
I thought I should start making some small contibutions before 7.0.

Attached is a patch to the old problem discussed feverly before 6.5.
What is does:
for locale-enabled servers:
use index if last char before '%' is ascii.
for non-locale servers:
do not use locale if last char is non-ascii since it is wrong anyway.

Comments?

I tried your patches but it seems malformed:

patch: **** unexpected end of file in patch

Yes, I had to apply it manually.

So this is a guess from reading them. I think your pacthes break
non-ascii multi-byte character sets data and should be surrounded by
#ifdef LOCALE rather than replacing current codes surrounded by
#ifndef LOCALE.

Can you supply a patch against the current tree? I don't understand
this. Thanks.

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

From bouncefilter Mon Nov 29 20:53:09 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA46414
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 20:52:51 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA20933;
Mon, 29 Nov 1999 20:52:43 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300152.UAA20933@candle.pha.pa.us>
Subject: Re: indexable and locale
In-Reply-To: <38076E23.DF48EB24@kirra.net> from Goran Thyni at "Oct 15, 1999
08:10:43 pm"
To: Goran Thyni <goran@kirra.net>
Date: Mon, 29 Nov 1999 20:52:43 -0500 (EST)
CC: PostgreSQL-development <hackers@postgreSQL.org>,
Bruce Momjian <maillist@candle.pha.pa.us>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Sorry, found messages of people objecting to the patch. Patch reversed
out.

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Hello again,
I thought I should start making some small contibutions before 7.0.

Attached is a patch to the old problem discussed feverly before 6.5.
What is does:
for locale-enabled servers:
use index if last char before '%' is ascii.
for non-locale servers:
do not use locale if last char is non-ascii since it is wrong anyway.

Comments?

regards,
--
-----------------
G_ran Thyni
On quiet nights you can hear Windows NT reboot!

diff -c pgsql/src/backend/optimizer/path/indxpath.c work/pgsql/src/backend/optimizer/path/indxpath.c
*** pgsql/src/backend/optimizer/path/indxpath.c	Wed Oct  6 18:33:57 1999
--- work/pgsql/src/backend/optimizer/path/indxpath.c	Fri Oct 15 19:54:34 1999
***************
*** 1934,1968 ****
op = makeOper(optup->t_data->t_oid, InvalidOid, BOOLOID, 0, NULL);
expr = make_opclause(op, leftop, (Var *) con);
result = lcons(expr, NIL);
- 
/*
! 	 * In ASCII locale we say "x <= prefix\377".  This does not
! 	 * work for non-ASCII collation orders, and it's not really
! 	 * right even for ASCII.  FIX ME!
! 	 * Note we assume the passed prefix string is workspace with
! 	 * an extra byte, as created by the xxx_fixed_prefix routines above.
*/
! #ifndef USE_LOCALE
! 	prefixlen = strlen(prefix);
! 	prefix[prefixlen] = '\377';
! 	prefix[prefixlen+1] = '\0';
! 
! 	optup = SearchSysCacheTuple(OPRNAME,
! 								PointerGetDatum("<="),
! 								ObjectIdGetDatum(datatype),
! 								ObjectIdGetDatum(datatype),
! 								CharGetDatum('b'));
! 	if (!HeapTupleIsValid(optup))
! 		elog(ERROR, "prefix_quals: no <= operator for type %u", datatype);
! 	conval = (datatype == NAMEOID) ?
! 		(void*) namein(prefix) : (void*) textin(prefix);
! 	con = makeConst(datatype, ((datatype == NAMEOID) ? NAMEDATALEN : -1),
! 					PointerGetDatum(conval),
! 					false, false, false, false);
! 	op = makeOper(optup->t_data->t_oid, InvalidOid, BOOLOID, 0, NULL);
! 	expr = make_opclause(op, leftop, (Var *) con);
! 	result = lappend(result, expr);
! #endif
! 
return result;
}
--- 1934,1970 ----
op = makeOper(optup->t_data->t_oid, InvalidOid, BOOLOID, 0, NULL);
expr = make_opclause(op, leftop, (Var *) con);
result = lcons(expr, NIL);
/*
! 	 * If last is in ascii range make it indexable,
! 	 * else let it be.
! 	 * FIXME: find way to use locate for this to support
! 	 *        indexing of non-ascii characters.
*/
! 	prefixlen = strlen(prefix) - 1;
! 	elog(DEBUG, "XXX1 %s", prefix);
! 	if ((unsigned) prefix[prefixlen] < 126)
! 	  {
! 	    prefix[prefixlen]++;
! 	    elog(DEBUG, "XXX2 %s", prefix);
! 	    optup = SearchSysCacheTuple(OPRNAME,
! 					PointerGetDatum("<="),
! 					ObjectIdGetDatum(datatype),
! 					ObjectIdGetDatum(datatype),
! 					CharGetDatum('b'));
! 	    if (!HeapTupleIsValid(optup))
! 	      elog(ERROR, "prefix_quals: no <= operator for type %u", datatype);
! 	    conval = (datatype == NAMEOID) ?
! 	      (void*) namein(prefix) : (void*) textin(prefix);
! 	    con = makeConst(datatype, ((datatype == NAMEOID) ? NAMEDATALEN : -1),
! 			    PointerGetDatum(conval),
! 			    false, false, false, false);
! 	    op = makeOper(optup->t_data->t_oid, InvalidOid, BOOLOID, 0, NULL);
! 	    expr = make_opclause(op, leftop, (Var *) con);
! 	    result = lappend(result, expr);
! 	  }
return result;
}

[application/x-gzip is not supported, skipping...]

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

From bouncefilter Mon Nov 29 20:54:08 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA46482
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 20:53:21 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
UAA20942;
Mon, 29 Nov 1999 20:52:56 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300152.UAA20942@candle.pha.pa.us>
Subject: Re: [HACKERS] indexable and locale
In-Reply-To: <5492.940095061@sss.pgh.pa.us> from Tom Lane at "Oct 16,
1999 01:31:01 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 20:52:56 -0500 (EST)
CC: t-ishii@sra.co.jp, Goran Thyni <goran@kirra.net>,
PostgreSQL-development <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Here is Tom's comment on the patch.

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

Attached is a patch to the old problem discussed feverly before 6.5.

... I think your pacthes break
non-ascii multi-byte character sets data and should be surrounded by
#ifdef LOCALE rather than replacing current codes surrounded by
#ifndef LOCALE.

I am worried about this patch too. Under MULTIBYTE could it
generate invalid characters? Also, do all non-ASCII locales sort
codes 0-126 in the same order as ASCII? I didn't think they do,
but I'm not an expert.

The approach I was considering for fixing the problem was to use a
loop that would repeatedly try to generate a string greater than the
prefix string. The basic loop step would increment the rightmost
byte as Goran has done (or, if it's already up to the limit, chop
it off and increment the next character position). Then test to
see whether the '<' operator actually believes the result is
greater than the given prefix, and repeat if not. This avoids making
any strong assumptions about the sort order of different character
codes. However, there are two significant issues that would have
to be surmounted to make it work reliably:

1. In MULTIBYTE mode incrementing the rightmost byte might yield
an illegal multibyte character. Some way to prevent or detect this
would be needed, lest it confuse the comparison operator. I think
we have some multibyte routines that could be used to check for
a valid result, but I haven't looked into it.

2. I think there are some locales out there that have context-
sensitive sorting rules, ie, a given character string may sort
differently than you'd expect from considering the characters in
isolation. For example, in German isn't "ss" treated specially?
If "pqrss" does not sort between "pqrs" and "pqrt" then the entire
premise of *both* sides of the LIKE optimization falls apart,
because you can't be sure what will happen when comparing a prefix
string like "pqrs" against longer strings from the database.
I do not know if this is really a problem, nor what we could do
to avoid it if it is.

regards, tom lane

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

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

From bouncefilter Mon Nov 29 21:03:08 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA48185
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 21:02:53 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA21215;
Mon, 29 Nov 1999 21:02:40 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300202.VAA21215@candle.pha.pa.us>
Subject: Re: [HACKERS] sort on huge table
In-Reply-To: <199910190849.RAA29403@srapc451.sra.co.jp> from Tatsuo Ishii at
"Oct 19, 1999 05:49:22 pm"
To: t-ishii@sra.co.jp
Date: Mon, 29 Nov 1999 21:02:40 -0500 (EST)
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Was this resolved?

That's what I get for not testing the interaction between logtape.c
and buffile.c at a segment boundary --- it didn't work, of course :-(.
I rebuilt with a small RELSEG_SIZE and debugged it. I'm still concerned
about possible integer overflow problems, so please update and try again
with a large file.

It worked with 2GB+ table but was much slower than before.

Before(with 8MB sort memory): 22 minutes

After(with 8MB sort memory): 1 hour and 5 minutes
After(with 80MB sort memory): 42 minutes.
--
Tatsuo Ishii

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

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

From bouncefilter Mon Nov 29 21:10:08 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA49355
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 21:09:24 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA18745;
Mon, 29 Nov 1999 21:07:13 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Bizarre coding in _bt_binsrch
In-reply-to: Your message of Mon, 29 Nov 1999 17:24:37 -0500 (EST)
<199911292224.RAA15252@candle.pha.pa.us>
Date: Mon, 29 Nov 1999 21:07:12 -0500
Message-ID: <18743.943927632@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Tom, I assume you have dealt with this, right?

I have been puzzling out the coding in _bt_binsrch() in
backend/access/nbtree/nbtsearch.c, with an eye to speeding it up for
the many-equal-keys case.

I tweaked the code to go faster in the equal-keys case, but Vadim later
pointed out that what we *really* should do is force the algorithms to
never consider two index keys equal (eg, by including the heap tuple id
as the last part of the comparison key). See his pgsql-hackers message
dated 06 Jun 1999 21:32:36 +0800. Getting the full benefit would
require ripping out the BTP_CHAIN logic and doing some other major
surgery, so I don't feel like I know the btree code well enough to
tackle it. It should be on the TODO list though:

* Include heap CTID in btree index keys, remove equal-key cruft from btree

regards, tom lane

From bouncefilter Mon Nov 29 21:12:10 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA50142
for <hackers@postgreSQL.org>; Mon, 29 Nov 1999 21:11:52 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA18777;
Mon, 29 Nov 1999 21:09:29 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Edmund Mergl <E.Mergl@bawue.de>, Oleg Bartunov <oleg@sai.msu.su>,
hackers@postgreSQL.org
Subject: Re: [HACKERS] destroydb doesn't close connection with client (httpd
<-> pg)
In-reply-to: Your message of Mon, 29 Nov 1999 17:25:02 -0500 (EST)
<199911292225.RAA15288@candle.pha.pa.us>
Date: Mon, 29 Nov 1999 21:09:29 -0500
Message-ID: <18775.943927769@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Can someone comment on where we are on this?

Problem's gone: you cannot destroy a DB containing active backends
anymore. That may not be quite the solution Edmund wanted ;-), but
it's effective.

Create and fill a database. Connect to this database with psql
and perform some query. Without disconnecting destroy and re-create
the database but insert this time different data. Performing
the same query a second time will retrieve the same data as before

regards, tom lane

From bouncefilter Mon Nov 29 21:15:10 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA50483;
Mon, 29 Nov 1999 21:14:27 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA18805;
Mon, 29 Nov 1999 21:12:45 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Massimo Dal Zotto <dz@cs.unitn.it>,
PostgreSQL Hackers <hackers@postgreSQL.org>,
Pgsql Patches <pgsql-patches@postgreSQL.org>
Subject: Re: [PATCHES] Re: [HACKERS] new patches
In-reply-to: Your message of Mon, 29 Nov 1999 17:25:57 -0500 (EST)
<199911292225.RAA15312@candle.pha.pa.us>
Date: Mon, 29 Nov 1999 21:12:45 -0500
Message-ID: <18803.943927965@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Tom, any comment on this?

I believe all those patches are applied long since in current sources
(Massimo might want to check though).

I even did something about QueryCancel in vacuum yesterday...

regards, tom lane

Massimo Dal Zotto <dz@cs.unitn.it> writes:

Two small patches:
1) make default NBuffers = DEF_MAXBACKENDS*2 as required by check in
PostmasterMain().

I had proposed moving NDBUFS into config.h and fixing the default a few
days ago, but then forgot to do it. As things stand, if you increase
DEF_MAXBACKENDS at configure time, you'll get a postmaster that won't
start unless you give it a -B setting larger than default. This is bad,
and I agree with Massimo that we ought to make sure the default NBuffers
is one that will work with the default MaxBackends.

This patch is not quite right though, since it doesn't account for the
other part of PostmasterMain's condition (NBuffers >= 16). Will fix.

2) check for QueryCancel in the copy command. Maybe we should do the
same in vacuum command (Vadim?).

I'm not too excited about adding QueryCancel support so soon before the
release, but the part of your patch that you didn't mention (diking out
the "file_opened" hack) is really a critical fix --- as the code stood
it would try to fclose() the same stdio file twice, which is disastrous
in most stdio libraries. I applied that part of it... good catch!

From bouncefilter Mon Nov 29 21:14:09 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA50356
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 21:13:34 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA21480;
Mon, 29 Nov 1999 21:13:23 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300213.VAA21480@candle.pha.pa.us>
Subject: Re: [HACKERS] Bizarre coding in _bt_binsrch
In-Reply-To: <18743.943927632@sss.pgh.pa.us> from Tom Lane at "Nov 29,
1999 09:07:12 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 21:13:23 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Tom, I assume you have dealt with this, right?

I have been puzzling out the coding in _bt_binsrch() in
backend/access/nbtree/nbtsearch.c, with an eye to speeding it up for
the many-equal-keys case.

I tweaked the code to go faster in the equal-keys case, but Vadim later
pointed out that what we *really* should do is force the algorithms to
never consider two index keys equal (eg, by including the heap tuple id
as the last part of the comparison key). See his pgsql-hackers message
dated 06 Jun 1999 21:32:36 +0800. Getting the full benefit would
require ripping out the BTP_CHAIN logic and doing some other major
surgery, so I don't feel like I know the btree code well enough to
tackle it. It should be on the TODO list though:

* Include heap CTID in btree index keys, remove equal-key cruft from btree

Thanks. That's what I needed.

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

From bouncefilter Mon Nov 29 21:17:09 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA51125
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 21:17:08 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA18828;
Mon, 29 Nov 1999 21:15:22 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: "[Jos_] Soares" <jose@sferacarta.com>,
hackers <pgsql-hackers@postgreSQL.org>
Subject: Re: [HACKERS] having bug report
In-reply-to: Your message of Mon, 29 Nov 1999 17:27:30 -0500 (EST)
<199911292227.RAA15325@candle.pha.pa.us>
Date: Mon, 29 Nov 1999 21:15:22 -0500
Message-ID: <18826.943928122@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Any comments on that status of this one?

Those particular cases are fixed, I think, but there are still severe
problems with VIEWs that use grouping or aggregates. I doubt we can
improve the VIEW situation much more without subselects-in-FROM.

regards, tom lane

* subqueries containing HAVING return incorrect results

select istat from comuni where istat in (
select istat from comuni group by istat having count(istat) > 1
);
ERROR: rewrite: aggregate column of view must be at rigth side in qual

select istat from comuni where istat in (
select istat from comuni group by istat having 1 < count(istat)
);
ERROR: pull_var_clause: Cannot handle node type 108

From bouncefilter Mon Nov 29 21:22:08 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA51874;
Mon, 29 Nov 1999 21:21:52 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA18851;
Mon, 29 Nov 1999 21:20:36 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Uncle George <gatgul@voicenet.com>, Jan Wieck <wieck@debis.com>,
pgsql-hackers@postgresql.org, pgsql-ports@postgresql.org
Subject: Re: [PORTS] Re: [HACKERS] RedHat6.0 & Alpha
In-reply-to: Your message of Mon, 29 Nov 1999 17:46:02 -0500 (EST)
<199911292246.RAA16125@candle.pha.pa.us>
Date: Mon, 29 Nov 1999 21:20:36 -0500
Message-ID: <18849.943928436@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Any ideas on this one?

Uncle George <gatgul@voicenet.com> writes:

In the regression test rules.sql there is this SQL command
update rtest_v1 set a = rtest_t3.a + 20 where b = rtest_t3.b;
Which causes my alpha port to go core.

Yeah. This was reported by Pedro Lobo on 11 June, and we've been
patiently waiting for Jan to decide what to do about it :-(

You could stop the coredump by putting a test into ResolveNew:

{
*nodePtr = copyObject(n);
+ if (IsA(*nodePtr, Var))
((Var *) *nodePtr)->varlevelsup = this_varlevelsup;
}

but what's not so clear is what's supposed to happen when the
replacement item *isn't* a Var.  I tried to convince myself that nothing
needed to happen in that case, but wasn't successful.  (Presumably the
replacement expression contains no instances of the variable being
replaced, so recursing into it with ResolveNew shouldn't be needed
--- but maybe its varlevelsup values need adjusted?)

That code currently reads like:

/* Make a copy of the tlist item to return */
n = copyObject(n);
if (IsA(n, Var))
{
((Var *) n)->varlevelsup = this_varlevelsup;
}
/* XXX what to do if tlist item is NOT a var?
* Should we be using something like apply_RIR_adjust_sublevel?
*/
return n;

so it won't coredump when the tlist item is not a Var, but I'm not
convinced it does the right thing either. Jan is the only man who
understands that code well enough to say what needs to be done about
it...

regards, tom lane

From bouncefilter Mon Nov 29 21:32:13 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA53925
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 21:31:18 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA22088;
Mon, 29 Nov 1999 21:28:28 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300228.VAA22088@candle.pha.pa.us>
Subject: Re: A bug in NOT IN (SELECT ...
In-Reply-To: <381E9CCB.A46CDF62@tm.ee> from Hannu Krosing at "Nov 2,
1999 08:11:55 am"
To: Hannu Krosing <hannu@tm.ee>
Date: Mon, 29 Nov 1999 21:28:28 -0500 (EST)
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
PostgreSQL-development <pgsql-hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can you be more specific about the problem?

Hi,

Pleas post this to approproiate lists also, as I'm currently
rejected from lists due to address change.

I am running 6.5.2 on RH Linux 6.0 and I have a following bug
(the dump of two tables involved is attached)

hannu=> select title from document where subject not in (
hannu-> select full_path from group_directory);
title
-----
(0 rows)

hannu=> select title from document where not subject in (
hannu-> select full_path from group_directory);
testcert
.
.
.
tester
tester
lugu
hlhkllk
(26 rows)

What's even more scary is that a little after trying to get it
work right and doing the first query a lot, I got a server crash
with corrupted shared memory, that had to be cured with a reboot
(was faster than finding docs for ipcclean)

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

From bouncefilter Mon Nov 29 21:33:09 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA54137
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 21:32:55 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA18884;
Mon, 29 Nov 1999 21:28:50 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: phd2@earthling.net, PostgreSQL-development <pgsql-hackers@postgreSQL.org>,
Artem Chuprina <ran@pirit.com>
Subject: Re: [HACKERS] Bug
In-reply-to: Your message of Mon, 29 Nov 1999 18:12:36 -0500 (EST)
<199911292312.SAA16911@candle.pha.pa.us>
Date: Mon, 29 Nov 1999 21:28:49 -0500
Message-ID: <18882.943928929@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

It appears this bug still exists.

Yes. I think this cannot be fixed without having a two-level querytree
structure for INSERT ... SELECT. The problem is basically that the
DISTINCT processing is happening on the tuples that are ready to put
into the target table (after the 'n' column is added), rather than on
the tuples that are coming out of the source table. With only one
targetlist there is no way to represent the notion that the DISTINCT
needs to happen on just the 't' column.

This is one of a large number of things waiting for a redesign of
querytrees...

regards, tom lane

ran=> create table test1 (n int default nextval('seq_test'), t text);

ran=> insert into test1 ("t") select distinct src from test_source;

ran=> select * from test1;
n|t
-+---------------
1|First distinct
2|First distinct
3|Second distinct
4|Second distinct
(4 rows)

From bouncefilter Mon Nov 29 21:33:08 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA54111
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 21:32:38 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA18915;
Mon, 29 Nov 1999 21:30:58 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
Peter Eisentraut <peter_e@gmx.net>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Tricky query, tricky response
In-reply-to: Your message of Mon, 29 Nov 1999 18:27:34 -0500 (EST)
<199911292327.SAA17484@candle.pha.pa.us>
Date: Mon, 29 Nov 1999 21:30:58 -0500
Message-ID: <18913.943929058@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

No nested CASE's?

Looks like not. I would guess that it is fairly straightforward to
fix, but am not sure. Tom Lane hunted down an killed most of the CASE
problems (thanks Tom!), and this is in an area he is working on now.
Maybe you can get him to look at it??

Is this an item for the TODO list?

Fixed in current sources, I believe.

regards, tom lane

From bouncefilter Mon Nov 29 21:38:08 1999
Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA54965
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 21:37:21 -0500 (EST)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id VAA18931;
Mon, 29 Nov 1999 21:34:48 -0500 (EST)
To: Bruce Momjian <pgman@candle.pha.pa.us>
cc: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] union and LIMIT problem
In-reply-to: Your message of Mon, 29 Nov 1999 19:29:05 -0500 (EST)
<199911300029.TAA18425@candle.pha.pa.us>
Date: Mon, 29 Nov 1999 21:34:48 -0500
Message-ID: <18929.943929288@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

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

Can I assume this is fixed? I see it marked on the TODO list.

Yes, I think it is (barring a counterexample from someone ... the
UNION rewriter is awfully crufty ...).

It might be nice to allow LIMIT to be attached to subselects rather
than just the top level, but I have no idea what it would take in the
executor to implement that. I could handle fixing the parser & planner
if someone else wants to fix it in the executor.

Does anybody know how to use UNION and LIMIT together ?

select msg_id from publications union
select key_id from keys limit 10
produces something I wasn't expected

regards, tom lane

From bouncefilter Mon Nov 29 21:44:09 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA57916
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 21:43:37 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA22632;
Mon, 29 Nov 1999 21:40:55 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300240.VAA22632@candle.pha.pa.us>
Subject: Re: [HACKERS] IN clause and INTERSECT not behaving as expected
In-Reply-To: <19991105010629.A16230@loopy.berkhirt.com> from Brian Hirt at
"Nov
7, 1999 12:54:37 pm"
To: bhirt@mobygames.com
Date: Mon, 29 Nov 1999 21:40:55 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Can anyone comment on this?

Hello,

I was writing a query using intersect and came across a strang error.
Independently, the two queries work fine but fail to compile when
intersected. My first instinct was to rewrite the query with an
in clause, and that too failed in even a stranger way. I've stripped
down the queries to the most basic case of failure. I'm running 6.5.3
on a RedHat 6.0 PII. I've included a little snippet of code to reproduce
the problem. I'm expecting to hear that you can't have aggregates in
IN clauses until the rewrite engine gets fixed -- discussed in previous
posts. I'm more hopefull that the intersection problem will be easy to
solve.

/* create test tables and test data */
create table test1 (id int);
create table test2 (id int, fk int);
insert into test1 values (1);
insert into test1 values (2);
insert into test2 values (1,100);
insert into test2 values (1,102);
insert into test2 values (2,100);
insert into test2 values (3,101);

/* QUERY 1: this query works */
select id from test1;

/* QUERY 2: this query works */
select id from test2 group by id having count(fk) = 2;

/* QUERY 3: intersected, the queries fail with:
* ERROR: SELECT/HAVING requires aggregates to be valid
* NOTE: reversing the order of the intersection works */
select id from test1
intersect
select id from test2 group by id having count(fk) = 2;

/* QUERY 4: using "QUERY 2" as an in clause you get a more confusing error:
* ERROR: rewrite: aggregate column of view must be at rigth side in qual */
select id from test1 where id in
(select id from test2 group by id having count(fk) = 2);

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

http://www.mobygames.com

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

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

From bouncefilter Mon Nov 29 21:49:09 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA59052
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 21:48:15 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA22646;
Mon, 29 Nov 1999 21:41:44 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300241.VAA22646@candle.pha.pa.us>
Subject: Re: [HACKERS] union and LIMIT problem
In-Reply-To: <18929.943929288@sss.pgh.pa.us> from Tom Lane at "Nov 29,
1999 09:34:48 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 21:41:44 -0500 (EST)
CC: Oleg Bartunov <oleg@sai.msu.su>, pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

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

Can I assume this is fixed? I see it marked on the TODO list.

Yes, I think it is (barring a counterexample from someone ... the
UNION rewriter is awfully crufty ...).

It might be nice to allow LIMIT to be attached to subselects rather
than just the top level, but I have no idea what it would take in the
executor to implement that. I could handle fixing the parser & planner
if someone else wants to fix it in the executor.

Let's wait for someone to ask for it.

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

From bouncefilter Mon Nov 29 22:00:09 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA62201
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 22:00:06 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
VAA22996;
Mon, 29 Nov 1999 21:57:34 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300257.VAA22996@candle.pha.pa.us>
Subject: Re: [HACKERS] Arrays broken on temp tables
In-Reply-To: <13765.942296690@sss.pgh.pa.us> from Tom Lane at "Nov 11,
1999 00:04:50 am"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 21:57:34 -0500 (EST)
CC: Bruce Momjian <maillist@candle.pha.pa.us>,
Kristofer Munn <kmunn@munn.com>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I believe this is fixed was fixed by my RelationGetRelationName and
RelationGetPhysicalRelationName.

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

The bottom line here is that we mustn't generate separate RTEs for the
logical and physical table names.

Are you saying a join on a temp table will not work?

Not at all; I'm saying that it's incorrect to generate a join for a
simple UPDATE. What we had was

UPDATE table SET arrayfield[sub] = val;

which is really implemented as (more or less)

UPDATE table SET arrayfield = ARRAYINSERT(arrayfield, sub, val);

which works fine as long as you apply the computation and update once
per tuple in the table (or once per tuple selected by WHERE, if there
is one). But for a temp table, what really gets emitted from the
parser is effectively like

UPDATE logtable SET arrayfield = arrayinsert(phytable.field,
sub, val)
FROM logtable phytable;

This is a Cartesian join, meaning that each tuple in
logtable-as-destination will be processed in combination with each tuple
in logtable-as-phytable. The particular case Kristofer reported
implements the join as a nested loop with logtable-as-destination as the
inner side of the join. So, each target tuple gets updated once with
an arrayfield value computed off each available source tuple --- and
when the dust settles, they've all got the value computed from the last
source tuple. That's why they're all the same in his bug report.

Adding a WHERE clause limits the damage, but the target tuples will all
still get the same value, if I'm visualizing the behavior correctly.
It's the wrong thing in any case; the very best you could hope for is
that the tuples all manage to get the right values after far more
processing than necessary. There should be no join for a simple UPDATE.

regards, tom lane

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

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

From bouncefilter Mon Nov 29 22:12:09 1999
Received: from candle.pha.pa.us (pgman@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id WAA63988
for <pgsql-hackers@postgreSQL.org>;
Mon, 29 Nov 1999 22:11:15 -0500 (EST)
(envelope-from pgman@candle.pha.pa.us)
Received: (from pgman@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id
WAA25206;
Mon, 29 Nov 1999 22:11:06 -0500 (EST)
From: Bruce Momjian <pgman@candle.pha.pa.us>
Message-Id: <199911300311.WAA25206@candle.pha.pa.us>
Subject: Re: [HACKERS] Status of sql_help.h
In-Reply-To: <1874.942531667@sss.pgh.pa.us> from Tom Lane at "Nov 13,
1999 05:21:07 pm"
To: Tom Lane <tgl@sss.pgh.pa.us>
Date: Mon, 29 Nov 1999 22:11:06 -0500 (EST)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL65 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

I see that src/bin/psql/sql_help.h is now generated automatically
from the SGML documentation. This is a Good Thing. But: since
sql_help.h is now a derived file, shouldn't it be removed from the
CVS repository, for the same reasons that we don't keep gram.c
and other derived files in CVS? If we leave it there, it'll generate
a lot of extra update traffic.

The only reason I can see for leaving it in CVS is that if we remove it,
people who pull sources from CVS would need Perl in order to build psql.
(People who download tarballs would *not*, since release_prep updates
sql_help.h along with the other derived files.) That's annoying, but
I think it may not be a fatal objection. Most hackers are probably
more likely to already have Perl than to already have bison or flex...

I thought about suggesting that create_help.pl be rewritten in some
"more portable" fashion such as an awk script. But really, if you
consider non-Unix platforms, Perl is more portable than awk or any
other likely alternative. (It might be worthwhile to remove the one
or two unnecessary Perl-5-isms in the script, so that it will run on
Perl 4 if that's what's available.)

Comments? Anyone feel that we really can't expect users of the CVS
repository to have Perl?

Because we have proper dependency, any change to sgml will force the
next committer to commit a new sql_help.h right? If so, seems like it
will work fine as is.

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