Re: [HACKERS] ERROR: infinite recursion in proc_exit

Kristofer Munn <kmunn@munn.com> writes:
> On a number of occasions over the past couple of weeks I have encountered
> the following error during my nightly vacuum process.  It repeats
> infinitely until outside intervention.  It seems to identify the fact that
> it is stuck in an infinite recursion but unable to deal with it.

What Postgres version are you using?  This loop:

> Nov  4 03:37:20 mymailman logger: pq_recvbuf: recv() failed: Bad file descriptor
> Nov  4 03:37:20 mymailman logger: FATAL 1:  Socket command type ? unknown 
> Nov  4 03:37:20 mymailman logger: pq_flush: send() failed: Bad file descriptor 
> Nov  4 03:37:20 mymailman logger: ERROR:  unknown frontend message was received 
> Nov  4 03:37:20 mymailman logger: pq_flush: send() failed: Bad file descriptor 
> Nov  4 03:37:20 mymailman logger: NOTICE:  AbortTransaction and not in in-progress state  
> Nov  4 03:37:20 mymailman logger: pq_flush: send() failed: Bad file descriptor 
> Nov  4 03:37:20 mymailman logger: pq_flush: send() failed: Bad file descriptor 
> Nov  4 03:37:20 mymailman logger: pq_recvbuf: recv() failed: Bad file descriptor

looks like we are trying to read a command from the frontend, failing
because the socket descriptor's been clobbered, trying to send the
elog() report to the client --- which also fails of course --- returning
to the main loop and failing again.  But as far as I can tell from
looking at either 6.5 or current code, that can't happen: a failure
return from pq_recvbuf should lead to proc_exit *without* reaching the
'Socket command type ? unknown' elog.  So I think you are working with
6.4 or older code, in which case an update would be your best bet.

If you want to try to recover without doing an update, I think you'll
still need to do a pg_dump/destroydb/createdb/reload.  It looks like
the indexes on pg_attribute have been corrupted, and there's not any
easier way to clean that up.  (If it were a user table, you could just
drop and recreate the index, but don't try that on pg_attribute...)
        regards, tom lane