Re: [HACKERS] ERROR: infinite recursion in proc_exit

Kristofer Munn <kmunn(at)munn(dot)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