entries in pg_shadow
Hi.
The entries entered in pg_shadow haven't ever worked for me. I've tried a
number of times without success. If I update a user in there and set a
password for them:
postgres=> select * from pg_shadow;
usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd|valuntil
---------+--------+-----------+--------+--------+---------+-------+----------------------------
postgres | 100|t |t |t |t | |Sat Jan31 01:00:00 2037 EST
user1 | 1001|f |t |f |t | |
equipment| 1004|f |t |f |t | MYPASS|
(3 rows)
This example assumes I've set my password to 'MYPASS'.
Now I change pg_hba.conf to have a:
host equipment 123.123.123.123 255.255.0.0 password
Assuming my IP is 123.123.123.123 and the database I need to connect to is
called equipment and the user is of course equipment...
I've restarted the server and...
Now I run off to my remote machine and try to connect...
psql -u -h test.mypostgresserverdomain.com equipment
Username: equipment
Password:
Connection to database 'equipment' failed.
Password authentication failed for user 'equipment'
Any ideas on what the heck I might be forgetting to do or not doing
properly?
I'm starting postgres up as:
su -l postgres -c 'exec /usr/local/pgsql/bin/postmaster
-D/dr/raid0/postgres/pgdata -d 1 -i -o "-E -F -S 16384 -o
/usr/local/pgsql/home/logfile" -s >> /usr/local/pgsql/home/errlog 2>&1
/usr/local/pgsql/home/errlog1 &'
In the server's errlog file I find:
Password authentication failed for user 'equipment'
It would be really nice if I'd see something like:
Sat Aug 28 21:43:39 EDT 1999 - Password authentication failed from
123.123.123.123 on database 'equipment'
-Michael
Michael Richards <miker@scifair.acadiau.ca> writes:
The entries entered in pg_shadow haven't ever worked for me. I've tried a
number of times without success. If I update a user in there and set a
password for them:
IIRC, the only way to set a password that actually works is ALTER USER.
The reason direct SQL hacking on pg_shadow doesn't work is that
pg_shadow isn't what the postmaster looks at (the PM itself can't do
database operations without getting into possible deadlock situations).
There's a flat text file somewhere that contains the Real Info. ALTER
USER and friends know to rewrite the flat file after updating pg_shadow.
This is documented somewhere, I think, but not nearly prominently
enough...
regards, tom lane
Import Notes
Reply to msg id not found: YourmessageofSat28Aug1999214029-0300Pine.BSF.4.10.9908282128080.33117-100000@scifair.acadiau.ca | Resolved by subject fallback
Hi.
The entries entered in pg_shadow haven't ever worked for me. I've tried a
number of times without success. If I update a user in there and set a
password for them:
postgres=> select * from pg_shadow;
usename |usesysid|usecreatedb|usetrace|usesuper|usecatupd|passwd|valuntil
---------+--------+-----------+--------+--------+---------+-------+----------------------------
postgres | 100|t |t |t |t | |Sat Jan31 01:00:00 2037 EST
user1 | 1001|f |t |f |t | |
equipment| 1004|f |t |f |t | MYPASS|
(3 rows)This example assumes I've set my password to 'MYPASS'.
Now I change pg_hba.conf to have a:
host equipment 123.123.123.123 255.255.0.0 passwordAssuming my IP is 123.123.123.123 and the database I need to connect to is
called equipment and the user is of course equipment...I've restarted the server and...
You may need to restart the postmaster, or do a dummy change to a user.
There is a flat file that contains the pg_shadow contents that gets
updated with normal USER commands, but SQL commands don't update it. It
is on our 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 19026From bouncefilter Wed Sep 1 19:33:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA56729
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Sep 1999 19:32:55 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id TAA26127;
Wed, 1 Sep 1999 19:30:26 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909012330.TAA26127@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <199908300202.LAA24878@srapc451.sra.co.jp> from Tatsuo Ishii at
"Aug 30, 1999 11:02:59 am"
To: t-ishii@sra.co.jp
Date: Wed, 1 Sep 1999 19:30:26 -0400 (EDT)
CC: The Hermit Hacker <scrappy@hub.org>, Tom Lane <tgl@sss.pgh.pa.us>,
pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Sun, 29 Aug 1999, Tom Lane wrote:
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
Are we going to release 6.5.2? If yes, then when?
Marc proposed Sept 1 (back on 8/15), and there were no objections...
And its still the date I'm planning around...So Wednesday this week :)
Marc,
Could you make a tarball of 6.5.2-beta or 6.5.2-release-candidate or
whatever so that volunteers could get it by anon ftp for testing?
I am now back, and have not yet branded the release as 6.5.2. I can do
it tonight.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Sep 1 19:58:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA60785
for <hackers@postgreSQL.org>; Wed, 1 Sep 1999 19:58:13 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id TAA27517;
Wed, 1 Sep 1999 19:56:06 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909012356.TAA27517@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <Pine.BSF.4.10.9908311649010.8660-100000@thelab.hub.org> from The
Hermit Hacker at "Aug 31, 1999 04:51:01 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Wed, 1 Sep 1999 19:56:06 -0400 (EDT)
CC: Tom Lane <tgl@sss.pgh.pa.us>, Massimo Dal Zotto <dz@wizard.net>,
PostgreSQL Hackers <hackers@postgreSQL.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Tue, 31 Aug 1999, Tom Lane wrote:
Massimo Dal Zotto <dz@wizard.net> writes:
May I ask that the patches I submitted two months ago for 6.5.0 are applied
at least to 6.5.2?
Here is the 6.5.1 version of my patches.I don't much care for QueryLimit (we got rid of that for a reason!)
nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe
enough... but are we in the business of adding features to 6.5.*,
even little ones? Maybe it should only go in current.6.5.x is supposed to be *only* fixes, no new features...but I'm curious as
to why these never got into v6.5.0 in the first place...
I applied the safe ones, like the copy.c one. People objected to most
of the others, for reasons I have forgotten.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Sep 1 19:58:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id TAA60774
for <hackers@postgreSQL.org>; Wed, 1 Sep 1999 19:58:04 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id TAA27531;
Wed, 1 Sep 1999 19:57:18 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909012357.TAA27531@candle.pha.pa.us>
Subject: Re: [HACKERS] PostgreSQL 6.5.2
In-Reply-To: <199908312043.WAA23661@nikita.wizard.net> from Massimo Dal Zotto
at "Aug 31, 1999 10:43:53 pm"
To: Massimo Dal Zotto <dz@wizard.net>
Date: Wed, 1 Sep 1999 19:57:18 -0400 (EDT)
CC: PostgreSQL Hackers <hackers@postgreSQL.org>,
The Hermit Hacker <scrappy@hub.org>
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
On Tue, 31 Aug 1999, Tom Lane wrote:
Massimo Dal Zotto <dz@wizard.net> writes:
May I ask that the patches I submitted two months ago for 6.5.0 are applied
at least to 6.5.2?
Here is the 6.5.1 version of my patches.I don't much care for QueryLimit (we got rid of that for a reason!)
nor for the FREE_TUPLE_MEMORY patch, but the rest of this looks safe
enough... but are we in the business of adding features to 6.5.*,
even little ones? Maybe it should only go in current.6.5.x is supposed to be *only* fixes, no new features...but I'm curious as
to why these never got into v6.5.0 in the first place...Because they were submitted a few days before the realease date. Bruce told
me they would go in 6.5.1 but apparently he has forgot them. I hope to see
them in 6.5.2.
Oh, I did? I forgot. Let me try now.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Sep 1 20:06:21 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA62048
for <hackers@postgreSQL.org>; Wed, 1 Sep 1999 20:06:15 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id UAA28496;
Wed, 1 Sep 1999 20:04:10 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909020004.UAA28496@candle.pha.pa.us>
Subject: Re: [HACKERS] Changes for 6.5.2 ?
In-Reply-To: <Pine.GSO.3.96.SK.990901100426.6807O-100000@ra> from Oleg
Bartunov
at "Sep 1, 1999 10:09:19 am"
To: Oleg Bartunov <oleg@sai.msu.su>
Date: Wed, 1 Sep 1999 20:04:10 -0400 (EDT)
CC: hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Is there Changes list for 6.5.2 ? I checked REL6_5 tree and didn't
find it. It seems that Vadim's patch for nbtinsert.c (row-reuse)
still didn't applied.
This patch prevents index file to grow indefinitely and I consider it
as a bug fix. It's not complete, index file still grow but with much
less factor.
I just got back from vacation, and will start on 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 19026From bouncefilter Wed Sep 1 20:06:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA62004
for <pgsql-hackers@postgreSQL.org>; Wed, 1 Sep 1999 20:05:37 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id UAA28708;
Wed, 1 Sep 1999 20:04:55 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909020004.UAA28708@candle.pha.pa.us>
Subject: Re: [HACKERS] Yacc output faulty ("current")
In-Reply-To: <199909010735.JAA09138@kirk.nads.de> from Rainer Klute at "Sep 1,
1999 09:35:32 am"
To: Rainer Klute <klute@nads.de>
Date: Wed, 1 Sep 1999 20:04:54 -0400 (EDT)
CC: pgsql-hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
[Charset ISO-8859-1 unsupported, filtering to ASCII...]
Hi,
when trying to compile the "current" sources under Solaris 2.5.1,
the yacc-generated C source in interfaces/ecpg/preproc/preproc.c
seems to be faulty:gcc -I../../../include -I../../../backend -I/usr/local/tcltk-8.0p2/include -Wall -Wmissing-prototypes -I../include -DMAJOR_VERSION=2 -DMINOR_VERSION=6 -DPATCHLEVEL=2 -DINCLUDE_PATH=\"/usr/local/pgsql-develop/include\" -c preproc.c
/usr/ccs/bin/yaccpar: In function `yyparse':
/usr/ccs/bin/yaccpar:275: warning: implicit declaration of function `yylex'
preproc.y:3822: parse error before `}'
/usr/ccs/bin/yaccpar:375: warning: label `yyerrlab' defined but not used
/usr/ccs/bin/yaccpar:165: warning: label `yynewstate' defined but not used
gmake[3]: *** [preproc.o] Error 1
gmake[3]: Leaving directory `/share/syswork2/sw/PostgreSQL/CURRENT/pgsql/src/interfaces/ecpg/preproc'Running preproc.y through Bison (under Linux) helped, but this is
of course no adequate solution.
Yes, we know. Will work in next release.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Sep 1 20:25:15 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA64669
for <hackers@postgreSQL.org>; Wed, 1 Sep 1999 20:24:46 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id VAA46967;
Wed, 1 Sep 1999 21:23:31 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 1 Sep 1999 21:23:30 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
Subject: Re: [HACKERS] Changes for 6.5.2 ?
In-Reply-To: <199909020004.UAA28496@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909012123270.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Already done :)
On Wed, 1 Sep 1999, Bruce Momjian wrote:
Is there Changes list for 6.5.2 ? I checked REL6_5 tree and didn't
find it. It seems that Vadim's patch for nbtinsert.c (row-reuse)
still didn't applied.
This patch prevents index file to grow indefinitely and I consider it
as a bug fix. It's not complete, index file still grow but with much
less factor.I just got back from vacation, and will start on 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************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Wed Sep 1 20:26:15 1999
Received: from candle.pha.pa.us (maillist@s5-03.ppp.op.net [209.152.195.67])
by hub.org (8.9.3/8.9.3) with ESMTP id UAA64973
for <hackers@postgreSQL.org>; Wed, 1 Sep 1999 20:25:49 -0400 (EDT)
(envelope-from maillist@candle.pha.pa.us)
Received: (from maillist@localhost)
by candle.pha.pa.us (8.9.0/8.9.0) id UAA00839;
Wed, 1 Sep 1999 20:23:35 -0400 (EDT)
From: Bruce Momjian <maillist@candle.pha.pa.us>
Message-Id: <199909020023.UAA00839@candle.pha.pa.us>
Subject: Re: [HACKERS] Changes for 6.5.2 ?
In-Reply-To: <Pine.BSF.4.10.9909012123270.8660-100000@thelab.hub.org> from The
Hermit Hacker at "Sep 1, 1999 09:23:30 pm"
To: The Hermit Hacker <scrappy@hub.org>
Date: Wed, 1 Sep 1999 20:23:35 -0400 (EDT)
CC: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
X-Mailer: ELM [version 2.4ME+ PL56 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Already done :)
On Wed, 1 Sep 1999, Bruce Momjian wrote:
Is there Changes list for 6.5.2 ? I checked REL6_5 tree and didn't
find it. It seems that Vadim's patch for nbtinsert.c (row-reuse)
still didn't applied.
I still need to do the HISTORY/Changes list, and mark all the files as 6.5.2.
--
Bruce Momjian | http://www.op.net/~candle
maillist@candle.pha.pa.us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026From bouncefilter Wed Sep 1 21:41:21 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id VAA74659
for <hackers@postgreSQL.org>; Wed, 1 Sep 1999 21:40:51 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id WAA47424;
Wed, 1 Sep 1999 22:39:32 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Wed, 1 Sep 1999 22:39:32 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: Oleg Bartunov <oleg@sai.msu.su>, hackers@postgreSQL.org
Subject: Re: [HACKERS] Changes for 6.5.2 ?
In-Reply-To: <199909020023.UAA00839@candle.pha.pa.us>
Message-ID: <Pine.BSF.4.10.9909012239211.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Wed, 1 Sep 1999, Bruce Momjian wrote:
Already done :)
On Wed, 1 Sep 1999, Bruce Momjian wrote:
Is there Changes list for 6.5.2 ? I checked REL6_5 tree and didn't
find it. It seems that Vadim's patch for nbtinsert.c (row-reuse)
still didn't applied.I still need to do the HISTORY/Changes list, and mark all the files as 6.5.2.
Oops...*hangs head* *waddles away*
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Sep 2 00:37: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 AAA99130
for <pgsql-hackers@postgreSQL.org>; Thu, 2 Sep 1999 00:36:46 -0400 (EDT)
(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id AAA08240
for <pgsql-hackers@postgreSQL.org>; Thu, 2 Sep 1999 00:36:10 -0400 (EDT)
To: pgsql-hackers@postgreSQL.org
Subject: md.c is feeling much better now, thank you
Date: Thu, 02 Sep 1999 00:36:10 -0400
Message-ID: <8238.936246970@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
Hiroshi spotted the fundamental problem we were having:
RelationFlushRelation would happily flush a relation-cache
entry that still had an open file entry at the md.c and fd.c
levels. This resulted in a permanent leak of md and vfd
file descriptors, which was most easily observable as a leakage
of kernel file descriptors (though fd.c would eventually
recycle same). smgrclose() in RelationFlushRelation fixes it.
While I was poking at this I found a number of other problems
in md.c having to do with multiple-segment relations. I believe
they're all fixed now. I have been able to run initdb and the
regression tests with a 64Kb segment size, which never worked
before.
I stuck my neck out to the extent of committing these changes
into 6.5.* as well as current. I'd recommend a few more days
of beta-testing before we release 6.5.2 ;-). Marc, can you
make a new 6.5.2 candidate tarball?
regards, tom lane
From bouncefilter Thu Sep 2 01:26:26 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 BAA04723
for <hackers@postgreSQL.org>; Thu, 2 Sep 1999 01:25:36 -0400 (EDT)
(envelope-from lockhart@alumni.caltech.edu)
Received: from alumni.caltech.edu (lockhart@localhost [127.0.0.1])
by localhost (8.8.7/8.8.7) with ESMTP id FAA08765;
Thu, 2 Sep 1999 05:25:01 GMT
Sender: lockhart@hub.org
Message-ID: <37CE0A2D.9C617A13@alumni.caltech.edu>
Date: Thu, 02 Sep 1999 05:25:01 +0000
From: Thomas Lockhart <lockhart@alumni.caltech.edu>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Milan Zamazal <pdm@debian.cz>
CC: hackers@postgreSQL.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
References: <199909010230.LAA23513@srapc451.sra.co.jp>
<37CC95B4.4501F393@alumni.caltech.edu> <87emgi519i.fsf@pdm.pvt.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
That shouldn't be too difficult, if we have an encoding
infomation with each text column or literal. Maybe now is the
time to introuce NCHAR?TL> I've been waiting for a go-ahead from folks who would use
TL> it. imho the way to do it is to use Postgres' type system to
TL> implement it, rather than, for example, encoding "type"
TL> information into each string. We can also define a "default
TL> encoding" for each database as a new column in pg_database...
What about sorting? Would it be possible to solve it in similar way?
If I'm not mistaken, there is currently no good way to use two different
kinds of sorting for one postmaster instance?
Each encoding/character set can behave however you want. You can reuse
collation and sorting code from another character set, or define a
unique one.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
From bouncefilter Thu Sep 2 02:48:27 1999
Received: from kodu.home.ee (isdn-54.uninet.ee [194.204.0.118])
by hub.org (8.9.3/8.9.3) with ESMTP id CAA27314
for <hackers@postgresql.org>; Thu, 2 Sep 1999 02:48:07 -0400 (EDT)
(envelope-from hannu@trust.ee)
Received: from trust.ee (hannu@localhost [127.0.0.1])
by kodu.home.ee (8.8.7/8.8.7) with ESMTP id JAA00501;
Thu, 2 Sep 1999 09:52:27 +0300
Sender: hannu@kodu.home.ee
Message-ID: <37CE1EAB.7C8A7F62@trust.ee>
Date: Thu, 02 Sep 1999 09:52:27 +0300
From: Hannu Krosing <hannu@trust.ee>
Organization: Trust-O-Matic =?iso-8859-1?Q?O=DC?=
X-Mailer: Mozilla 4.5 [en] (X11; U; Linux 2.2.6 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Thomas Lockhart <lockhart@alumni.caltech.edu>
CC: Milan Zamazal <pdm@debian.cz>, hackers@postgresql.org
Subject: Re: [HACKERS] Implications of multi-byte support in a distribution
References: <199909010230.LAA23513@srapc451.sra.co.jp>
<37CC95B4.4501F393@alumni.caltech.edu> <87emgi519i.fsf@pdm.pvt.net>
<37CE0A2D.9C617A13@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Thomas Lockhart wrote:
That shouldn't be too difficult, if we have an encoding
infomation with each text column or literal. Maybe now is the
time to introuce NCHAR?TL> I've been waiting for a go-ahead from folks who would use
TL> it. imho the way to do it is to use Postgres' type system to
TL> implement it, rather than, for example, encoding "type"
TL> information into each string. We can also define a "default
TL> encoding" for each database as a new column in pg_database...
What about sorting? Would it be possible to solve it in similar way?
If I'm not mistaken, there is currently no good way to use two different
kinds of sorting for one postmaster instance?Each encoding/character set can behave however you want. You can reuse
collation and sorting code from another character set, or define a
unique one.
Is it really inside one postmaster instance ?
If so, then is the character encoding defined at the create table /
create index
process (maybe even separately for each field ?) or can I specify it
when sort'ing ?
-----------------
Hannu
From bouncefilter Thu Sep 2 06:31:30 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 GAA62158
for <pgsql-hackers@postgresql.org>; Thu, 2 Sep 1999 06:30:54 -0400 (EDT)
(envelope-from oleg@sai.msu.su)
Received: from ra (ra [158.250.29.2])
by ra.sai.msu.su (8.9.1/8.9.1) with SMTP id OAA05360
for <pgsql-hackers@postgresql.org>; Thu, 2 Sep 1999 14:30:49 +0400 (MSD)
Date: Thu, 2 Sep 1999 14:30:49 +0400 (MSD)
From: Oleg Bartunov <oleg@sai.msu.su>
X-Sender: megera@ra
To: pgsql-hackers@postgresql.org
Subject: Commercial question
Message-ID: <Pine.GSO.3.96.SK.990902142758.8507K-100000@ra>
Organization: Sternberg Astronomical Institute (Moscow University)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
I got a email from Russia with commercial questions.
Unfortunately it's written in russian. Whom I should forward
this message ?
Regards,
Oleg
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From bouncefilter Thu Sep 2 06:30:30 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 GAA61803
for <pgsql-hackers@postgreSQL.org>; Thu, 2 Sep 1999 06:29:48 -0400 (EDT)
(envelope-from Inoue@tpf.co.jp)
Received: from cadzone ([126.0.1.40] (may be forged))
by sd.tpf.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/8.8.4) with SMTP
id TAA05048; Thu, 02 Sep 1999 19:28:50 +0900
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Tom Lane" <tgl@sss.pgh.pa.us>
Cc: <pgsql-hackers@postgreSQL.org>
Subject: RE: [HACKERS] md.c is feeling much better now, thank you
Date: Thu, 2 Sep 1999 19:32:02 +0900
Message-ID: <000b01bef52e$6526e0a0$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: <8238.936246970@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: Thursday, September 02, 1999 1:36 PM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] md.c is feeling much better now, thank youHiroshi spotted the fundamental problem we were having:
RelationFlushRelation would happily flush a relation-cache
entry that still had an open file entry at the md.c and fd.c
levels. This resulted in a permanent leak of md and vfd
file descriptors, which was most easily observable as a leakage
of kernel file descriptors (though fd.c would eventually
recycle same). smgrclose() in RelationFlushRelation fixes it.
Thanks.
But I'm unhappy with your change for mdtruncate().
It's still dangerous to unlink unwanted segments in mdtruncte().
StartTransaction() and CommandCounterIncrement() trigger
relation cache invalidation. Unfortunately those are insufficient
to prevent backends from inserting into invalid relations.
For exmaple
If a backend is blocked by vacuum,it would insert into the target
relation without relation cache invalidation after vacuum.
It seems that other triggers are necessary around LockRelation().
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp
From bouncefilter Thu Sep 2 08:38:31 1999
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA78538
for <pgsql-hackers@postgresql.org>; Thu, 2 Sep 1999 08:37:34 -0400 (EDT)
(envelope-from leon@udmnet.ru)
Received: from udmnet.ru (A160.dialup.udm.net [213.24.0.160])
by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id RAA75413;
Thu, 2 Sep 1999 17:35:38 +0500 (SAMST)
Sender: leon@lota.izhcom.ru
Message-ID: <37CE6CA7.B34BD4CE@udmnet.ru>
Date: Thu, 02 Sep 1999 17:25:11 +0500
From: Leon <leon@udmnet.ru>
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.3-5 i686)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Postgres' lexer
References: <17693.936194114@sss.pgh.pa.us>
Content-Type: multipart/mixed; boundary="------------11C368001CBB014251CE71CA"
This is a multi-part message in MIME format.
--------------11C368001CBB014251CE71CA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Tom Lane wrote:
To my mind, without spaces this construction *is* ambiguous, and frankly
I'd have expected the second interpretation ('+-' is a single operator
name). Almost every computer language in the world uses "greedy"
tokenization where the next token is the longest series of characters
that can validly be a token. I don't regard the above behavior as
predictable, natural, nor obvious. In fact, I'd say it's a bug that
"3+-2" and "3+-x" are not lexed in the same way.
Completely agree with that. This differentiating behavior looks like a bug.
However, aside from arguing about whether the current behavior is good
or bad, these examples seem to indicate that it doesn't take an infinite
amount of lookahead to reproduce the behavior. It looks to me like we
could preserve the current behavior by parsing a '-' as a separate token
if it *immediately* precedes a digit, and otherwise allowing it to be
folded into the preceding operator. That could presumably be done
without VLTC.
Ok. If we *have* to preserve old weird behavior, here is the patch.
It is to be applied over all my other patches. Though if I were to
decide whether to restore old behavior, I wouldn't do it. Because it
is inconsistency in grammar, i.e. a bug.
--
Leon.
--------------11C368001CBB014251CE71CA
Content-Type: application/octet-stream; name="patch.weird_oper"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="patch.weird_oper"
KioqIHNjYW4ubC1ub2J1ZwlUaHUgU2VwICAyIDE2OjQ4OjIzIDE5OTkKLS0tIHNjYW4ubAlU
aHUgU2VwICAyIDE3OjE0OjQ3IDE5OTkKKioqKioqKioqKioqKioqCioqKiA4Niw5MSAqKioq
Ci0tLSA4Niw5MiAtLS0tCiAgJXggeGQKICAleCB4aAogICV4IHhxCisgJXggeG0KICAKICAv
KiBCaW5hcnkgbnVtYmVyCiAgICovCioqKioqKioqKioqKioqKgoqKiogMTQzLDE0OCAqKioq
Ci0tLSAxNDQsMTUwIC0tLS0KICBzZWxmCQkJWywoKVxbXF0uOyRcOlwrXC1cKlwvXCVcPFw+
XD1cfF0KICBvcF9hbmRfc2VsZgkJW1x+XCFcQFwjXF5cJlx8XGBcP1wkXDpcK1wtXCpcL1wl
XDxcPlw9XQogIG9wZXJhdG9yCQl7b3BfYW5kX3NlbGZ9KworIHVtaW51cyAtCiAgCiAgLyog
d2UgZG8gbm90IGFsbG93IHVuYXJ5IG1pbnVzIGluIG51bWJlcnMuIAogICAqIGluc3RlYWQg
d2UgcGFzcyBpdCB2ZXJiYXRpbSB0byBwYXJzZXIuIHRoZXJlIGl0IGdldHMKKioqKioqKioq
KioqKioqCioqKiAyNzgsMjgzICoqKioKLS0tIDI4MCwyOTkgLS0tLQogIAogIHtzZWxmfQkJ
CXsgCXJldHVybiB5eXRleHRbMF07IH0KICAKKyB7b3BlcmF0b3J9Ly1bXC4wLTldICAgICB7
CisgCQkJCQlCRUdJTih4bSk7CisgCQkJCQlpZiAoc3RyY21wKChjaGFyKil5eXRleHQsIiE9
IikgPT0gMCkKKyAJCQkJCQl5eWx2YWwuc3RyID0gcHN0cmR1cCgiPD4iKTsgLyogY29tcGF0
YWJpbGl0eSAqLworIAkJCQkJZWxzZQorIAkJCQkJCXl5bHZhbC5zdHIgPSBwc3RyZHVwKChj
aGFyKil5eXRleHQpOworIAkJCQkJcmV0dXJuIE9wOworIAkJCQl9CisgCQkJCQorIDx4bT57
dW1pbnVzfQl7CisgCQkJCQkJCQlCRUdJTihJTklUSUFMKTsKKyAJCQkJCQkJCXJldHVybiB5
eXRleHRbMF07CisgCQkJCQkJCX0KKyAJCQkJCQkJCiAge29wZXJhdG9yfQkJewogIAkJCQkJ
aWYgKHN0cmNtcCgoY2hhciopeXl0ZXh0LCIhPSIpID09IDApCiAgCQkJCQkJeXlsdmFsLnN0
ciA9IHBzdHJkdXAoIjw+Iik7IC8qIGNvbXBhdGFiaWxpdHkgKi8K
--------------11C368001CBB014251CE71CA--
From bouncefilter Thu Sep 2 08:43:31 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id IAA79180
for <pgsql-hackers@postgresql.org>; Thu, 2 Sep 1999 08:43:01 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id JAA51957;
Thu, 2 Sep 1999 09:43:12 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 2 Sep 1999 09:43:12 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Hiroshi Inoue <Inoue@tpf.co.jp>
cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: RE: [HACKERS] md.c is feeling much better now, thank you
In-Reply-To: <000b01bef52e$6526e0a0$2801007e@cadzone.tpf.co.jp>
Message-ID: <Pine.BSF.4.10.9909020942410.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I think that, based on this, the changes should be back'd out of v6.5.2
until further testing and analysis can be done. If we have to, we can do
a v6.5.3 at a later date, if you want to get this in then...
On Thu, 2 Sep 1999, Hiroshi Inoue wrote:
-----Original Message-----
From: owner-pgsql-hackers@postgreSQL.org
[mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Tom Lane
Sent: Thursday, September 02, 1999 1:36 PM
To: pgsql-hackers@postgreSQL.org
Subject: [HACKERS] md.c is feeling much better now, thank youHiroshi spotted the fundamental problem we were having:
RelationFlushRelation would happily flush a relation-cache
entry that still had an open file entry at the md.c and fd.c
levels. This resulted in a permanent leak of md and vfd
file descriptors, which was most easily observable as a leakage
of kernel file descriptors (though fd.c would eventually
recycle same). smgrclose() in RelationFlushRelation fixes it.Thanks.
But I'm unhappy with your change for mdtruncate().
It's still dangerous to unlink unwanted segments in mdtruncte().StartTransaction() and CommandCounterIncrement() trigger
relation cache invalidation. Unfortunately those are insufficient
to prevent backends from inserting into invalid relations.For exmaple
If a backend is blocked by vacuum,it would insert into the target
relation without relation cache invalidation after vacuum.It seems that other triggers are necessary around LockRelation().
Regards.
Hiroshi Inoue
Inoue@tpf.co.jp************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
From bouncefilter Thu Sep 2 09:03:38 1999
Received: from s-nath-exch2.nath-ctmp.co.za ([209.212.102.30])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA83606
for <pgsql-hackers@postgreSQL.org>; Thu, 2 Sep 1999 09:02:37 -0400 (EDT)
(envelope-from Michael.Ansley@intec.co.za)
Received: by S-NATH-EXCH2 with Internet Mail Service (5.5.2448.0)
id <RF19KMY1>; Thu, 2 Sep 1999 14:58:33 +0200
Message-ID: <1BF7C7482189D211B03F00805F8527F748C02C@S-NATH-EXCH2>
From: "Ansley, Michael" <Michael.Ansley@intec.co.za>
To: "'Leon'" <leon@udmnet.ru>, Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Lockhart <lockhart@alumni.caltech.edu>,
pgsql-hackers@postgreSQL.org
Subject: RE: [HACKERS] Postgres' lexer
Date: Thu, 2 Sep 1999 14:58:31 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2448.0)
Content-Type: text/plain;
charset="iso-8859-1"
To my mind, without spaces this construction *is* ambiguous, and
frankly
I'd have expected the second interpretation ('+-' is a single operator
name). Almost every computer language in the world uses "greedy"
tokenization where the next token is the longest series of characters
that can validly be a token. I don't regard the above behavior as
predictable, natural, nor obvious. In fact, I'd say it's a bug that
"3+-2" and "3+-x" are not lexed in the same way.Completely agree with that. This differentiating behavior looks like a
bug.
However, aside from arguing about whether the current behavior is good
or bad, these examples seem to indicate that it doesn't take an
infinite
amount of lookahead to reproduce the behavior. It looks to me like we
could preserve the current behavior by parsing a '-' as a separate
token
if it *immediately* precedes a digit, and otherwise allowing it to be
folded into the preceding operator. That could presumably be done
without VLTC.Ok. If we *have* to preserve old weird behavior, here is the patch.
It is to be applied over all my other patches. Though if I were to
decide whether to restore old behavior, I wouldn't do it. Because it
is inconsistency in grammar, i.e. a bug.
If a construct is ambiguous, then the behaviour should be undefined (i.e.:
we can do what we like, within reason). If the user wants something
predictable, then she should use brackets ;-)
If 3+-2 presents an ambiguity (which it does) then make sure that you do
this: 3+(-2). If you have an operator +- then you should do this (3)+-(2).
However, if you have 3+-2 without brackets, then, because this is ambiguous
(assuming no +- operator), this is undefined, and we can do pretty much
whatever we feel like with it. Unless there is an operator +- defined,
because then the behaviour is no longer ambiguous. The longest possible
identifier is always matched, and this means that the +- will be identified.
Especially with the unary minus, my feeling is that it should be placed in
brackets if correct behaviour is desired.
MikeA
From bouncefilter Thu Sep 2 09:08:38 1999
Received: from thelab.hub.org (nat203.199.mpoweredpc.net [142.177.203.199])
by hub.org (8.9.3/8.9.3) with ESMTP id JAA85568
for <pgsql-hackers@postgreSQL.org>; Thu, 2 Sep 1999 09:08:31 -0400 (EDT)
(envelope-from scrappy@hub.org)
Received: from localhost (scrappy@localhost)
by thelab.hub.org (8.9.3/8.9.1) with ESMTP id KAA52136;
Thu, 2 Sep 1999 10:05:41 -0300 (ADT) (envelope-from scrappy@hub.org)
X-Authentication-Warning: thelab.hub.org: scrappy owned process doing -bs
Date: Thu, 2 Sep 1999 10:05:41 -0300 (ADT)
From: The Hermit Hacker <scrappy@hub.org>
To: Oleg Bartunov <oleg@sai.msu.su>
cc: pgsql-hackers@postgreSQL.org
Subject: Re: [HACKERS] Commercial question
In-Reply-To: <Pine.GSO.3.96.SK.990902142758.8507K-100000@ra>
Message-ID: <Pine.BSF.4.10.9909021005220.8660-100000@thelab.hub.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
good question...Vadim? Don't you speak Russian? :)
On Thu, 2 Sep 1999, Oleg Bartunov wrote:
Hi,
I got a email from Russia with commercial questions.
Unfortunately it's written in russian. Whom I should forward
this message ?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************
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org