Hmm, all the crashes you show us below sound like resource exhaustion
issues. That's a nice way to say your feeding silly SQL to the server,
and it's _trying_ to do what you ask... How are you driving the server?
psql? some sort of CGI? We need more info to help you debug what's
happening.
In particular, the 'parser: parse error' problems are exactly that:
the parser was handed something that it can't grok. Admitedly, the error
message is not particularly useful, bug that's being worked on. It would
help if you turned on some debugging, so you could see what the backend
is trying to do when it crashes. I find -d3 useful for this sort of
thing; warning though: it _will_ generate large log files.
What do you mean by a crash, btw? a backend dies, or the postmaster dies,
or the kernel goes down?
Ross
On Thu, Mar 09, 2000 at 10:45:05AM -0800, Garry Dolley wrote:
>
> su postgres -l -c '/usr/bin/postmaster -i > /var/lib/pgsql /pgserver.log
> 2>&1' &
>
> ERROR: parser: parse error at or near ""
> ERROR: parser: parse error at or near ""
> FATAL 1: ReleaseLruFile: No opened files - no one can be closed
Looks like a resource leak on the parser error path , specifically
file handles.
>
> Another time:
>
> FATAL 1: Memory exhausted in AllocSetAlloc()
> NOTICE: AbortTransaction and not in in-progress state
> FATAL 1: Memory exhausted in AllocSetAlloc()
> FATAL 1: Memory exhausted in AllocSetAlloc()
> FATAL 1: Memory exhausted in AllocSetAlloc()
> FATAL 1: Memory exhausted in AllocSetAlloc()
> out of dynamic memory in yy_create_buffer()
> FATAL 1: Memory exhausted in AllocSetAlloc()
> FATAL 1: Memory exhausted in AllocSetAlloc()
> FATAL 1: Memory exhausted in AllocSetAlloc()
>
We're still failing in the parser here: yy_create_buffer() is trying
to expand
> After these, I changed the way I started Postgres (increased buffers,
> etc...):
>
> su postgres -l -c '/usr/bin/postmaster -i -B 256 -N 128 >
> /var/lib/pgsql/pgserver.log 2>&1' &
Hmm, what do you mean by high load? Do you really have 128 simultanious
backends running?
>
> But there are still crashes, so here's the output from the last crash:
>
> pq_flush: send() failed: Broken pipe
> FATAL: pq_endmessage failed: errno=32
> pq_flush: send() failed: Broken pipe
> FATAL: pq_endmessage failed: errno=32
> pq_flush: send() failed: Broken pipe
> FATAL: pq_endmessage failed: errno=32
> pq_flush: send() failed: Broken pipe
> FATAL: pq_endmessage failed: errno=32
> pq_flush: send() failed: Broken pipe
> pq_recvbuf: unexpected EOF on client connection
>
> And another time:
>
> ERROR: parser: parse error at or near ""
> ERROR: parser: parse error at or near ""
> ERROR: parser: parse error at or near ""
> ERROR: parser: parse error at or near ""
> FATAL 1: Database system does not exist. PGDATA directory
> '/var/lib/pgsql' not found.
> Normally, you create a database system by running initdb.
> FATAL 1: ReleaseLruFile: No opened files - no one can be closed
> pq_recvbuf: unexpected EOF on client connection
> pq_flush: send() failed: Broken pipe
> pq_recvbuf: unexpected EOF on client connection
>
These last few sound like you've damaged your DB installation, perhaps
from the resource exhaustion problem from earlier.
--
Ross J. Reedstrom, Ph.D., <[EMAIL PROTECTED]>
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St., Houston, TX 77005
