Re: [ADMIN] Longest name for table/column/key/index

2004-10-17 Thread Bruce Momjian
Joost Kraaijeveld wrote: > Hi all, > > Are there any limits to the length of the names of tables, columns, primary keys and > indexes in PostgreSQL? 63 characters by default. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-100

[ADMIN] Longest name for table/column/key/index

2004-10-17 Thread Joost Kraaijeveld
Hi all, Are there any limits to the length of the names of tables, columns, primary keys and indexes in PostgreSQL? Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: [EMAIL PROTECTED] web: www.askesis.nl -

Re: [ADMIN] Suppressing duplicate key error messages in

2004-10-17 Thread Larry Lennhoff
At 05:24 PM 10/17/2004, Tom Lane wrote: Larry Lennhoff <[EMAIL PROTECTED]> writes: > Is there any way to suppress this message so that it won't appear in the > log? I looked at the documentation and log_min_error_statement looked > promising. I set it to panic, but the messages continue. What am

Re: [ADMIN] set AUTOCOMMIT OFF in psqlrc not having affect

2004-10-17 Thread Bruce Momjian
Christian Fowler wrote: > > Thanks Tom, it appears that was the issue. Bruce, it would appear it > was at some point? Glad to hear it's now insensitive. Yes, it was always true until a few days ago. Sorry that wasn't clear. -- Bruce Momjian| http://candle.pha.pa.us

Re: [ADMIN] Single table vacuum full different when vacuum full the whole

2004-10-17 Thread Gaetano Mendola
Tom Lane wrote: > Gaetano Mendola <[EMAIL PROTECTED]> writes: > >>it seems that a vacuum full on the whole DB is more aggressive. > > > It is not. > > A much more plausible theory is that this is the result of concurrent > changes to the table. It is clear from the "dead row versions" stats > that

Re: [ADMIN] Single table vacuum full different when vacuum full the whole database

2004-10-17 Thread Tom Lane
Gaetano Mendola <[EMAIL PROTECTED]> writes: > it seems that a vacuum full on the whole DB is more aggressive. It is not. A much more plausible theory is that this is the result of concurrent changes to the table. It is clear from the "dead row versions" stats that there were concurrent transacti

[ADMIN] Single table vacuum full different when vacuum full the whole database

2004-10-17 Thread Gaetano Mendola
Hi all, I'm experiencing different behaviour if a vacuum full a single table or the whole DB: SINGLE TABLE: # vacuum full verbose ua_user_data_exp; INFO: vacuuming "public.ua_user_data_exp" INFO: "ua_user_data_exp": found 36 removable, 34519 nonremovable row versions in 22662 pages DETAIL: 82 d

Re: [ADMIN] Problem in starting postgres server on sun solaris 5.7

2004-10-17 Thread Gregory S. Williamson
As root you will need to edit the /etc/system file to add some information for the OS about how much RAM to use for shared memory. These are settings for Informix (don't have a postgres SUN setup at hand and don't have doucumentation either): set shmsys:shminfo_shmmax=1205306368 set semsys:sem

Re: [ADMIN] set AUTOCOMMIT OFF in psqlrc not having affect

2004-10-17 Thread Christian Fowler
Thanks Tom, it appears that was the issue. Bruce, it would appear it was at some point? Glad to hear it's now insensitive. On Sun, 17 Oct 2004, Bruce Momjian wrote: FYI, it is not case-sensitive in current CVS. Tom Lane wrote: Christian Fowler <[EMAIL PROTECTED]> writes: I have \set AUTOCOMMIT O

Re: [ADMIN] Suppressing duplicate key error messages in

2004-10-17 Thread Tom Lane
Larry Lennhoff <[EMAIL PROTECTED]> writes: > Is there any way to suppress this message so that it won't appear in the > log? I looked at the documentation and log_min_error_statement looked > promising. I set it to panic, but the messages continue. What am I doing > wrong? [ slightly more awake

Re: [ADMIN] Suppressing duplicate key error messages in

2004-10-17 Thread Larry Lennhoff
At 11:59 PM 10/16/2004, Tom Lane wrote: Larry Lennhoff <[EMAIL PROTECTED]> writes: > Is there any way to suppress this message so that it won't appear in the > log? I looked at the documentation and log_min_error_statement looked > promising. I set it to panic, but the messages continue. What am

[ADMIN] Problem in starting postgres server on sun solaris 5.7

2004-10-17 Thread Dattaram Shivji
Hi! I installed postgresql-7.2.1 on Sun solaris 5.7 running on sparc processor. while installing i had no problems but as soon as start with following line /usr/local/pgsql/bin/postmaster -D /user2/pgsql/data or /usr/local/pgsql/bin/pg_ctl -D /user2/pgsql/data -l logfile start kailas#

Re: [ADMIN] set AUTOCOMMIT OFF in psqlrc not having affect

2004-10-17 Thread Bruce Momjian
FYI, it is not case-sensitive in current CVS. --- Tom Lane wrote: > Christian Fowler <[EMAIL PROTECTED]> writes: > > I have \set AUTOCOMMIT OFF in my .psqlrc and it seems psql seems to not > > have any effect. > > I think

Re: [ADMIN] set AUTOCOMMIT OFF in psqlrc not having affect

2004-10-17 Thread Tom Lane
Christian Fowler <[EMAIL PROTECTED]> writes: > I have \set AUTOCOMMIT OFF in my .psqlrc and it seems psql seems to not > have any effect. I think the value is case-sensitive. Try \set AUTOCOMMIT off regards, tom lane ---(end of broadcast)

[ADMIN] set AUTOCOMMIT OFF in psqlrc not having affect

2004-10-17 Thread Christian Fowler
I have \set AUTOCOMMIT OFF in my .psqlrc and it seems psql seems to not have any effect. Am I missing something? I've been googling and googling and seem a bit lost at this point. [EMAIL PROTECTED] host]$ cat ~/.psqlrc \set AUTOCOMMIT OFF \echo 'AUTOCOMMIT is' :AUTOCOMMIT \set PROMPT1 'host.%/%R