Thread: probs with postgres

probs with postgres

From
"Christopher Kings-Lynne"
Date:
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



Re: probs with postgres

From
Tom Lane
Date:
"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


Re: probs with postgres

From
"Christopher Kings-Lynne"
Date:
> "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

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 nullname    |
charactervarying(32)    | not nullval     | 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



Re: probs with postgres

From
Tom Lane
Date:
"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