From: | Jack Orenstein <jorenstein(at)archivas(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jack Orenstein <jao(at)geophile(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Why is psql \copy process stuck? |
Date: | 2005-05-14 18:22:40 |
Message-ID: | 428641F0.3000301@archivas.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Jack Orenstein <jorenstein(at)archivas(dot)com> writes:
>
>>I'm not sure I did this right, (it's been a while since I worked with
>>gdb). But here's what I found.
>
>
> Doesn't look like either of those can be trusted very far :-(. But both
> of them seem to be waiting for input.
>
> What this looks like to me is some kind of networking problem. Perhaps
> the connection to the remote host got dropped and the local kernel
> hasn't realized it yet? From memory, we use TCP KEEPALIVE on the
> server socket but not in client-side code, so there's probably not any
> timeout that will trigger in anything like a sane amount of time.
>
> On the other hand, if the remote backend didn't die immediately, it
> *would* have recognized a network timeout and gone away in at most an
> hour or so. Did you check for any "unexpected EOF on client connection"
> or similar messages in the remote postmaster's log?
I did check, and didn't see any such message.
Jack Orenstein
From | Date | Subject | |
---|---|---|---|
Next Message | Raymond O'Donnell | 2005-05-14 18:41:04 | libpq.dll causing access violation |
Previous Message | Tom Lane | 2005-05-14 18:15:41 | Re: Why is psql \copy process stuck? |