Thomas Munro <thomas.mu...@enterprisedb.com> writes: > On Tue, May 16, 2017 at 6:29 PM, Vaishnavi Prabakaran > <vaishnaviprabaka...@gmail.com> wrote: >> Hi, I could not reproduce this issue. Even after Ctrl+d , subsequent COPY >> from commands reads the input properly. Is there any specific step you >> followed or can you share the sample testcase?
> Hmm. Doesn't happen on GNU/Linux, does happen on macOS and FreeBSD. Hah, confirmed here. Thinking about it, it seems like glibc must be exceeding its authority to make this work on Linux; I don't know of anything in POSIX saying that the eof indicator should go away without a clearerr() call. In fact, it seems like glibc is violating its own documentation --- "man feof" saith The function feof() tests the end-of-file indicator for the stream pointed to by stream, returning non-zero if it is set. The end-of-file indicator can only be cleared by the function clearerr(). I had been supposing that this was a feature addition and should be left for the next commitfest. But given that it already works as-expected on popular platform(s), the fact that it doesn't work the same on some other platforms seems like a portability bug rather than a missing feature. Now I'm inclined to treat it as a bug and back-patch. Reviewing the actual patch, though ... there seem to be paths through handleCopyIn that would not hit this, particularly the sigsetjmp path. It's unlikely that we'd get control-C before we finish servicing control-D, but maybe not impossible. Wouldn't it be better just to do an unconditional clear at the end, maybe copyin_cleanup: + /* In case input is from a tty, reset the EOF indicator. */ + clearerr(copystream); + /* * Check command status and return to normal libpq state. * (I'd be inclined to make the comment significantly more verbose than that, btw.) regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers