Thread: pg_attribute_relid_attnam_index problem after log disk filled up

Hi!

What's this? What to do? Shall I bother?

pp=> vacuum;
NOTICE:  Index pg_attribute_relid_attnam_index: NUMBER OF
INDEX' TUPLES (3094) IS NOT THE SAME AS HEAP' (3093)

The database is rather large, and the time to run vacuum is too
short, so it feels like something is stopping the vacuum too
early. The problem started when the log partition (where
postmaster logging output is written) was full, and some
backends crashed. This is fixed, but it seems that postgres is
not fully recovered.

PostgreSQL 6.5.2 on i386-unknown-freebsd3.3, compiled by cc 
Running on FreeBSD 3.5-RELEASE  (SMP kernel).

Cheers,
Palle

--         Partitur Informationsteknik AB    
Wenner-Gren Center             +46 8 566 280 02  
113 46 Stockholm           +46 70 785 86 02  
Sweden                   girgen@partitur.se

Palle Girgensohn <girgen@partitur.se> writes:
> What's this? What to do? Shall I bother?

> pp=> vacuum;
> NOTICE:  Index pg_attribute_relid_attnam_index: NUMBER OF
> INDEX' TUPLES (3094) IS NOT THE SAME AS HEAP' (3093)

Under 6.5, if vacuum doesn't get rid of the message then I think the
only way to do so is to dump and reload the database.  (I'd strongly
recommend updating to 7.0.2 while you do that.)

The message in itself is not catastrophic, but it does raise the
question of what other damage there might be.  Updating would be
a good idea anyway, considering all the bugs that got fixed between
6.5 and 7.0.

> The problem started when the log partition (where
> postmaster logging output is written) was full, and some
> backends crashed.

Did they actually crash, or just hang up waiting for space to become
available for the log file?  That really shouldn't have been much of
a problem, AFAICS.
        regards, tom lane

Tom Lane wrote:
> 
> Palle Girgensohn <girgen@partitur.se> writes:
> > What's this? What to do? Shall I bother?
> 
> > pp=> vacuum;
> > NOTICE:  Index pg_attribute_relid_attnam_index: NUMBER OF
> > INDEX' TUPLES (3094) IS NOT THE SAME AS HEAP' (3093)
> 
> Under 6.5, if vacuum doesn't get rid of the message then I think the
> only way to do so is to dump and reload the database.  (I'd strongly
> recommend updating to 7.0.2 while you do that.)
> 
> The message in itself is not catastrophic, but it does raise the
> question of what other damage there might be.  Updating would be
> a good idea anyway, considering all the bugs that got fixed between
> 6.5 and 7.0.

I continued this discussion, in more depth, on the pgsql-admin
list. I finally "gave up" and dumped|restored, updating not
7.0.2, but 6.5.3, since we are not just ready testing our
application with pg7 yet. soon. There are som futile, but
still, SQL differences.

> > The problem started when the log partition (where
> > postmaster logging output is written) was full, and some
> > backends crashed.
> 
> Did they actually crash, or just hang up waiting for space to become
> available for the log file?  That really shouldn't have been much of
> a problem, AFAICS.

Crashed when I killed them, if memory serves me (maybe the sig
6 ones, but I can't verify 100%).

$ dmesg
.....
pid 52915 (postgres), uid 70 on /usr/local: file system full
[logging was to /usr/local  *blush* :-/ ]
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 52915 (postgres), uid 70 on /usr/local: file system full
pid 53230 (postgres), uid 70: exited on signal 6 (core dumped)
pid 53357 (postgres), uid 70: exited on signal 6 (core dumped)
pid 53479 (postgres), uid 70: exited on signal 11 (core dumped)
pid 53481 (postgres), uid 70: exited on signal 11 (core dumped)
pid 53505 (postgres), uid 70: exited on signal 11 (core dumped)
pid 53510 (postgres), uid 70: exited on signal 11 (core dumped)


Cheers,
Palle