Re: [HACKERS] Continued problems with pgdump, Large Objects and crashing backends

Peter T Mount <peter(at)retep(dot)org(dot)uk> writes:
> However, this fails when creating functions that have more than one sql
> statement in them. He has some functions that insert into a table
> depending on some arguments, then issue a select on the last arg which is
> the functions result. However, pgdump doesn't end the select with a ; and
> this causes the 6.5 backend to fail. Adding the ; fixes the problem.

What does 'fail' mean exactly? Crash, or just reject the query?
It sounds like there is a pg_dump bug here (omitting a required
semicolon) but I don't understand whether there's also a backend bug.

> Running the backed with the -d2 flag, these expand to:

> pq_recvbuf: recv() failed, errno 2
> proc_exit(0) [#0]
> shmem_exit(0) [#0]
> exit(0)
> /usr/local/pgsql/bin/postmaster: reaping dead processes...
> /usr/local/pgsql/bin/postmaster: CleanupProc: pid 6731 exited with status 0
> pq_recvbuf: recv() failed, errno 0
> proc_exit(0) [#0]
> shmem_exit(0) [#0]
> exit(0)
> /usr/local/pgsql/bin/postmaster: reaping dead processes...
> /usr/local/pgsql/bin/postmaster: CleanupProc: pid 6730 exited with status 0

This doesn't look like a segv trace to me --- if the backend was
coredumping then the postmaster should see a nonzero exit status.

The recv() complaints probably indicate that the client application
disconnected ungracefully (ie, without sending the 'X' terminate
message). It's curious that they're not both alike.
That might be a red herring however --- right now pq_recvbuf doesn't
distinguish plain EOF from a true error, and if it's plain EOF then
whatever errno was last set to gets printed. Think I'll go fix that.

Barring more evidence, all I see here is client disconnect, not a
backend failure. What's your basis for claiming a segv crash?

> Ok, now the problem. When he sets autocommit to false, the JDBC driver
> sends BEGIN to the backend. Ok so far, however, something then fails
> during the first large object's load, and causes everything else to fail.

That's not a bug, it's a feature ... allegedly, anyway. Any error
inside a transaction means the entire transaction is aborted. And
the backend will keep reminding you so until you cooperate by ending
the transaction. I don't like the behavior very much either, but
it's operating as designed.

regards, tom lane