Well, setting query_cancel then seems like a logical solution because it
will exit at a reasonable point, hopefully. Right now we have
statement_timeout and that exits at a give time, but I suppose it
doesn't exit while data is transfering, so it may be different.
---
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Well, if we get an I/O error, I can't imagine why we would continue
> doing anything --- are any of those recoverable?
Well, that's what's not clear --- it's hard to tell if a write failure
is a hard error or just transient. If we make like elog(ERROR),
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Why is COMMERROR not doing the longjump like ERROR?
>
> Because it's defined to be like LOG.
>
> A more useful reply might be that I'm not sure it's safe to abort in the
> client I/O routines.
Well, if we get an I/O error, I can't i
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Why is COMMERROR not doing the longjump like ERROR?
Because it's defined to be like LOG.
A more useful reply might be that I'm not sure it's safe to abort in the
client I/O routines.
regards, tom lane
--
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > As part of the training class I did, some people tested what happens
> > when the client allocates tons of memory to store a result and aborts.
>
> > What we found was that though elog was properly called:
>
> > elog(COMMERROR, "
Bruce Momjian <[EMAIL PROTECTED]> writes:
> As part of the training class I did, some people tested what happens
> when the client allocates tons of memory to store a result and aborts.
> What we found was that though elog was properly called:
> elog(COMMERROR, "pq_recvbuf: recv() failed: %
As part of the training class I did, some people tested what happens
when the client allocates tons of memory to store a result and aborts.
What we found was that though elog was properly called:
elog(COMMERROR, "pq_recvbuf: recv() failed: %m");
(I think that was the message.) the backe
