probs with postgres
I keep getting this:
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3195 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3196 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3197 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3198 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3199 -
fixing
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3200 -
fixing
What could be causing it?
It occurs during Vacuum I think. We have been having a lot of load problems
with Postgres since we launched our new site a day ago and now this problem
has cropped up. users_sessions is probably our most-written row.
Postgres 7.3.2.
Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
I keep getting this:
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page 3195 -
fixing
Hmm. In 7.2.* I'd have said this was a known problem, but in 7.3.* it's
not. Want to dig into it? This is what I know about the 7.2 problem:
http://fts.postgresql.org/db/mw/msg.html?mid=1357214
regards, tom lane
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
I keep getting this:
2003-03-20 08:15:49 WARNING: Rel users_sessions: Uninitialized page
3195 -
fixing
Hmm. In 7.2.* I'd have said this was a known problem, but in 7.3.* it's
not. Want to dig into it? This is what I know about the 7.2 problem:
OK, well I can tell you this at the moment:
1. We're running 7.3.2
2. We do an hourly VACUUM ANALYZE. I do the odd VACUUM FULL (not on that
table) when I do large changes to tables.
3. users_sessions has heaps and heaps of reads and updates regular scan
deletes. There are lots of SELECT..FOR UPDATEs done on the table
4. Table def:
usa=# \d users_sessions
Table "public.users_sessions"
Column | Type | Modifiers
---------+--------------------------+------------------------
sid | character varying(32) | not null
name | character varying(32) | not null
val | text |
changed | timestamp with time zone | not null default 'now'
uid | integer | not null
Indexes: users_sessions_pkey primary key btree (sid, name),
users_sessions_cha_name_idx btree (changed, name),
users_sessions_uid_idx btree (uid)
5. We have been having load and stability problems with our Postgres since
we released a massive upgrade to our website. We did actually have one time
when Postgres crashed and the whole server rebooted when we got a bunch of
these:
Mar 20 09:25:54 serendipity /kernel: pmap_collect: collecting pv entries --
suggest increasing PMAP_SHPGPERPROC
Mar 20 09:27:09 serendipity /kernel: pmap_collect: collecting pv entries --
suggest increasing PMAP_SHPGPERPROC
Mar 20 09:28:29 serendipity last message repeated 2 times
Mar 20 09:29:42 serendipity /kernel: pmap_collect: collecting pv entries --
suggest increasing PMAP_SHPGPERPROC
So I reduced our shared buffers by a few thousand and I'm waiting on our
sysadmin to up the max pages per proc in the kernel.
Any ideas on anything I can look into?
Chris
"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
5. We have been having load and stability problems with our Postgres since
we released a massive upgrade to our website. We did actually have one time
when Postgres crashed and the whole server rebooted when we got a bunch of
these:
Mar 20 09:25:54 serendipity /kernel: pmap_collect: collecting pv entries --
suggest increasing PMAP_SHPGPERPROC
[blink...] Perhaps you should be asking hard questions about the
stability of your kernel. What are you running, anyway?
This is not to say that Postgres might not have its own problems --- but
Postgres is an unprivileged process. If your kernel is crashing, it is
not Postgres that's broken.
regards, tom lane