Re: [ADMIN] Stupid mistake: Forgot to dump when upgrading. (7.3 - 7.4.2)

2004-06-23 Thread Kevin Schroeder
Try re-installing PostgreSQL, dumping it, then re-installing the new
version.

Kevin

- Original Message - 
From: Jón Ragnarsson [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 23, 2004 12:29 PM
Subject: [ADMIN] Stupid mistake: Forgot to dump when upgrading. (7.3 -
7.4.2)


 I upgraded Postgres on my computer and forgot to dump the data. (Yes,
 very stupid) And now 7.4.2 refuses to read the datafiles. Is there
 anything that I can do?
 Maybe I should ask people over at redhat/fedora if I could downgrade
 Postgres?
 J.

 ---(end of broadcast)---
 TIP 6: Have you searched our list archives?

http://archives.postgresql.org




---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


[ADMIN] Shared memory error using initdb on Solaris 8

2004-05-21 Thread Kevin Schroeder
Hello,
I'm trying to install PostgreSQL 7.4.2 on a brand new SunFire 120 with
2GB of RAM but when I run initdb -D /usr/local/pgsql/data I get the
following error:

creating directory /usr/local/pgsql/data... ok
creating directory /usr/local/pgsql/data/base... ok
creating directory /usr/local/pgsql/data/global... ok
creating directory /usr/local/pgsql/data/pg_xlog... ok
creating directory /usr/local/pgsql/data/pg_clog... ok
selecting default max_connections... 10
selecting default shared_buffers... 50
creating configuration files... ok
creating template1 database in /usr/local/pgsql/data/base/1... FATAL:  could
not create shared memory segment: Invalid argument
DETAIL:  Failed system call was shmget(key=1, size=1081344, 03600).
HINT:  This error usually means that PostgreSQL's request for a shared
memory segment exceeded your kernel's SHMMAX parameter.  You can either
reduce the request size or reconfigure the kernel with larger SHMMAX.  To
reduce the request size (currently 1081344 bytes), reduce PostgreSQL's
shared_buffers parameter (currently 50) and/or its max_connections parameter
(currently 10).
If the request size is already small, it's possible that it is less
than your kernel's SHMMIN parameter, in which case raising the request size
or reconfiguring SHMMIN is called for.
The PostgreSQL documentation contains more information about shared
memory configuration.

initdb: failed
initdb: removing data directory /usr/local/pgsql/data

When I run ulimit -a I get

time(seconds)unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes)8192
coredump(blocks) 0
nofiles(descriptors) 256
vmemory(kbytes)  unlimited

There does not seem to be an option in initdb to reduce the shared buffers
size.  Plus, with 2GB of RAM I don't know that I'd want to go below the
lowest common denominator that Postgres defaults to.

Kevin


---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings


Re: [ADMIN] Shared memory error using initdb on Solaris 8

2004-05-21 Thread Kevin Schroeder
There we go.  For reference, what page did you get that info and what did
you search for to get it?

Kevin

- Original Message - 
From: Jim Seymour [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 21, 2004 10:57 AM
Subject: Re: [ADMIN] Shared memory error using initdb on Solaris 8


 
  Hello,
  I'm trying to install PostgreSQL 7.4.2 on a brand new SunFire 120
with
  2GB of RAM but when I run initdb -D /usr/local/pgsql/data I get the
  following error:
 
 [snip]
  creating template1 database in /usr/local/pgsql/data/base/1... FATAL:
could
  not create shared memory segment: Invalid argument
  DETAIL:  Failed system call was shmget(key=1, size=1081344, 03600).
  HINT:  This error usually means that PostgreSQL's request for a shared
  memory segment exceeded your kernel's SHMMAX parameter.
 [snip]
 
  When I run ulimit -a I get
 
 [snip]

 You're looking at the wrong thing.  You need to do:

 sysdef |egrep -i 'shm|sem'

 
  There does not seem to be an option in initdb to reduce the shared
buffers
  size.

 It tries to reduce things as far as it sanely can to fit within
 what's available.  You can hand-tweak initdb to over-ride its
 limits, but you'd end-up with a sub-optimal installation.

 Plus, with 2GB of RAM I don't know that I'd want to go below the
  lowest common denominator that Postgres defaults to.

 Nope.  You need to adjust certain values by placing settings in
 /etc/system and rebooting.  I use:

 /etc/system
 set shmsys:shminfo_shmmax=0x200  (33554432 decimal)
 set shmsys:shminfo_shmmin=1
 set shmsys:shminfo_shmmni=256
 set shmsys:shminfo_shmseg=256

 set semsys:seminfo_semmap=256
 set semsys:seminfo_semmni=512
 set semsys:seminfo_semmns=512
 set semsys:seminfo_semmsl=32

 I arrived at the above values from Google'ing.

 Jim

 ---(end of broadcast)---
 TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faqs/FAQ.html


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


Re: [ADMIN] Shared memory error using initdb on Solaris 8

2004-05-21 Thread Kevin Schroeder
Searching Google brought up this page.

http://www.postgresql.org/docs/current/interactive/kernel-resources.html



- Original Message - 
From: Jim Seymour [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, May 21, 2004 1:14 PM
Subject: Re: [ADMIN] Shared memory error using initdb on Solaris 8


 
  There we go.  For reference, what page did you get that info and what
did
  you search for to get it?

 Like I said: I derived it all from Google'ing on various search
 terms, IIRC.  Probably things like postgresql+Solaris+shmmax and
 the like.  I didn't save any URL references.

 Jim

 ---(end of broadcast)---
 TIP 8: explain analyze is your friend


---(end of broadcast)---
TIP 8: explain analyze is your friend


Re: [ADMIN] initdb error

2004-05-05 Thread Kevin Schroeder
That would seem to be the problem.

Thanks.

Kevin

- Original Message - 
From: Jim Seymour [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, May 04, 2004 6:26 PM
Subject: Re: [ADMIN] initdb error


 Kevin Schroeder [EMAIL PROTECTED] wrote:
 
  Hello,
  I'm trying to install PostgreSQL on Solaris 9.  Everything's
compiled
  properly but when I run initdb I get the following error:
 
 [snip]
  creating conversions... ERROR:  could not load library
  /usr/local/pgsql/lib/ascii_and_mic.so: ld.so.1:
  /usr/local/pgsql/bin/postgres: fatal: libgcc_s.so.1: open failed: No
such
  file or directory
 
  I found libgcc_s.so.1 in /usr/local/lib and that directory is in
  $LD_LIBRARY_PATH.  Is there anything that I'm missing here or that I
need to
  look for in my configure settings?

 Is that directory in LD_LIBRARY_PATH when you're su'd to the postgreSQL
 user?

 I added

 LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib; export
LD_LIBRARY_PATH

 to /etc/init.d/postgresql and created a .profile in its home directory
 with that in it.

 Solved all those problems :).

 You can also solve such problems by using the -R switch during build
 (man ld) and with Solaris 8/9's new crle utility.

 -- 
 Jim Seymour  | PGP Public Key available at:
 [EMAIL PROTECTED] |
http://www.uk.pgp.net/pgpnet/pks-commands.html
 http://jimsun.LinxNet.com|

 ---(end of broadcast)---
 TIP 8: explain analyze is your friend


---(end of broadcast)---
TIP 8: explain analyze is your friend


[ADMIN] initdb error

2004-05-04 Thread Kevin Schroeder
Hello,
I'm trying to install PostgreSQL on Solaris 9.  Everything's compiled
properly but when I run initdb I get the following error:

Sun Microsystems Inc.   SunOS 5.9   Generic May 2002
The files belonging to this database system will be owned by user pgsql.
This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory /usr/local/pgsql/data... ok
creating directory /usr/local/pgsql/data/base... ok
creating directory /usr/local/pgsql/data/global... ok
creating directory /usr/local/pgsql/data/pg_xlog... ok
creating directory /usr/local/pgsql/data/pg_clog... ok
selecting default max_connections... 40
selecting default shared_buffers... 800
creating configuration files... ok
creating template1 database in /usr/local/pgsql/data/base/1... ok
initializing pg_shadow... ok
enabling unlimited row size for system tables... ok
initializing pg_depend... ok
creating system views... ok
loading pg_description... ok
creating conversions... ERROR:  could not load library
/usr/local/pgsql/lib/ascii_and_mic.so: ld.so.1:
/usr/local/pgsql/bin/postgres: fatal: libgcc_s.so.1: open failed: No such
file or directory

I found libgcc_s.so.1 in /usr/local/lib and that directory is in
$LD_LIBRARY_PATH.  Is there anything that I'm missing here or that I need to
look for in my configure settings?

Kevin


---(end of broadcast)---
TIP 8: explain analyze is your friend


[ADMIN] Transaction log file screwed up

2004-04-22 Thread Kevin Schroeder
Hello,
A client database crashed last night and I think I found the solution to
the problem at http://www.varlena.com/varlena/GeneralBits/45.php Database
Recovery Procedures .  The solution was to append the file with enough
zeros to get the file size correct.  The solution was to run

dd bs=8k count=1  /dev/zero  $PGDATA/pg_clog/0005

which added the zeros to the end.  However my error values are a little
different from ones in the example and the person who posted this noted that
this should NOT be tried haphazardly.  Since I'd rather not crash a client's
database to the point of no recovery I wouldn't mind having someone with
more knowledge of PostgreSQL post the command with the correct arguments to
fix the problem, or tell me I'm off my rocker trying to fix it this way.

Following is pg_ctl's output when trying to start the database.  Following
that is the directory listing for the pg_clog directory.

LOG:  checkpoint record is at 1/383BDFC0
LOG:  redo record is at 1/383BDFC0; undo record is at 0/0; shutdown TRUE
LOG:  next transaction id: 15038948; next oid: 3293693
LOG:  database system was not properly shut down; automatic recovery in
progress
LOG:  ReadRecord: unexpected pageaddr 1/363BE000 in log file 1, segment 56,
offset 3923968
LOG:  redo is not required
PANIC:  XLogWrite: write request 1/383BE000 is past end of log 1/383BE000
LOG:  startup process (pid 1555) was terminated by signal 6
LOG:  aborting startup due to startup process failure

pgsql/data/pg_clog/*

-rw---1 postgres  postgres   262144 Mar 14 13:10 
-rw---1 postgres  postgres262144 Mar 24 15:35 0001
-rw---1 postgres  postgres262144 Mar 27 00:04 0002
-rw---1 postgres  postgres262144 Mar 29 18:06 0003
-rw---1 postgres  postgres262144 Apr  1 00:39 0004
-rw---1 postgres  postgres262144 Apr  3 09:54 0005
-rw---1 postgres  postgres262144 Apr  5 21:39 0006
-rw---1 postgres  postgres262144 Apr  8 03:26 0007
-rw---1 postgres  postgres262144 Apr 10 10:15 0008
-rw---1 postgres  postgres262144 Apr 12 21:05 0009
-rw---1 postgres  postgres262144 Apr 15 00:32 000A
-rw---1 postgres  postgres262144 Apr 17 03:38 000B
-rw---1 postgres  postgres262144 Apr 19 13:07 000C
-rw---1 postgres  postgres262144 Apr 21 13:38 000D
-rw---1 postgres  postgres 90112 Apr 22 07:01 000E

Thanks

Kevin


---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly