Re: [ADMIN] Crash with pg_clog file not found

2008-11-03 Thread Matthieu Roger
>>2008-10-31 20:17:32 CET 10.0.0.119 exile FATAL: connection limit >>exceeded for non-superusers > > This is just a wild guess, but how many connections are there? Especially see This link is interesting, I'm reading about it and found a good article on the msdn blog with a tool to check the desk

Re: [ADMIN] Lock them out?

2008-11-03 Thread Glyn Astill
> From: Carol Walter <[EMAIL PROTECTED]> > I'm running PostgreSQL version 8.2.10 on Solaris 10. > How can I lock > everyone out except the postgres user? > Do it in pg_hba.conf -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http:/

Re: [ADMIN] Lock them out?

2008-11-03 Thread Carol Walter
Thanks. That will work. I hadn't thought of that. Carol On Nov 3, 2008, at 10:11 AM, Glyn Astill wrote: From: Carol Walter <[EMAIL PROTECTED]> I'm running PostgreSQL version 8.2.10 on Solaris 10. How can I lock everyone out except the postgres user? Do it in pg_hba.conf -- Sent vi

Re: [ADMIN] Crash with pg_clog file not found

2008-11-03 Thread Tom Lane
"Matthieu Roger" <[EMAIL PROTECTED]> writes: > 2008-10-31 20:14:27 CET 10.0.0.119 exile PANIC: could not access > status of transaction 0 Can you present a self-contained test case that causes that? A stack trace from the PANIC would be mighty useful too, but I dunno whether there's any point in

Re: [ADMIN] Crash with pg_clog file not found

2008-11-03 Thread Matthieu Roger
2008/11/3 Tom Lane <[EMAIL PROTECTED]>: > "Matthieu Roger" <[EMAIL PROTECTED]> writes: >> 2008-10-31 20:14:27 CET 10.0.0.119 exile PANIC: could not access >> status of transaction 0 > > Can you present a self-contained test case that causes that? Hello Tom, we were not able to reproduce at will

[ADMIN] Lock them out?

2008-11-03 Thread Carol Walter
Greetings, I'm running PostgreSQL version 8.2.10 on Solaris 10. How can I lock everyone out except the postgres user? Carol -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin

Re: [ADMIN] Crash with pg_clog file not found

2008-11-03 Thread Rainer Bauer
"Matthieu Roger" wrote: >2008-10-31 20:17:32 CET 10.0.0.119 exile FATAL: connection limit >exceeded for non-superusers This is just a wild guess, but how many connections are there? Especially see

Re: [ADMIN] Crash with pg_clog file not found

2008-11-03 Thread Scott Marlowe
On Mon, Nov 3, 2008 at 8:49 AM, Matthieu Roger <[EMAIL PROTECTED]> wrote: > > 8.3.3 was also producing the same error, prior version (8.3.1) did not > seem to exhibit it, though we've opened a new universe in the web game > which increased the number of accounts and players in september so > maybe

[ADMIN] connect to psql without passwd

2008-11-03 Thread Isabella Ghiurea
I'm writing a shell script to run analyze and other jobs as use postgres, having issues passing the passwd in psql is always asking for password, I'm using .pgpass file as argument in psql ( I understood PGPASS is depreciated). My .pgpass file contains only the passwd string not the full conn

Re: [ADMIN] connect to psql without passwd

2008-11-03 Thread Milen A. Radev
Isabella Ghiurea написа: > I'm writing a shell script to run analyze and other jobs as use > postgres, having issues passing the passwd in psql is always asking for > password, I'm using .pgpass file as argument in psql ( I understood > PGPASS is depreciated). My .pgpass file contains only the pas

[ADMIN] many tables vs large tables

2008-11-03 Thread Kevin Neufeld
What is the general consensus around here ... to have many smaller tables, or have a few large tables? I'm looking at a db model where a client has around 5500 spatial (PostGIS) tables, where the volume of each one varies greatly ... from a few hundred rows to over 250,000. Speed is of the ut

[ADMIN] rebellious postgres process

2008-11-03 Thread Laszlo Nagy
This is what I see in "top" since two days: last pid: 95702; load averages: 2.48, 2.69, 2.75 up 3+02:08:49 10:27:58 257 processes: 3 running, 246 sleeping, 8 zombie CPU states: 15.5% user, 0.0% nice, 22.1% sy