Tom Lane <[EMAIL PROTECTED]> writes:
> In the second place, we don't treat communication failures as ERRORs,
> so how did step 3 happen?
You probably realize this, but just in case: "Broken Pipe" probably means the
backend received SIGPIPE, not just that some file operation syscall returned
-1.
There are a couple of big problems with this theory, though. In the
first place, there aren't any messages sent to the client during
post-commit; unless possibly it's an error message due to a failure
during post-commit, and that should have shown up in the server log.
In the second place, we do
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> Do you know what the dead client was doing?
> Unfortunately I don't. We didn't have PID logging turned on so I can't
> tell which process it was. The only thing I was told was,
> "I am running a Full Vacuum, CRAP the server just died ;)"
Hmm ... V
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
> 2005-06-27 16:37:53 ERROR: could not send data to client: Broken pipe
> 2005-06-27 16:37:53 PANIC: cannot abort transaction 146017848, it was
> already committed
A reasonable guess as to what happened there is:
1. Client process dies just as serv
Hello,
Any thoughts on the below? Specifically the PANIC? A customer
was performing a full vacuum when it happen. This is running 7.4.7
on ES 3.0. We run daily vacuums and analyzes as well.
2005-06-27 16:35:02 LOG: recycled transaction log file "004D006F"
2005-06-27 16:35:02 LOG: recyc
