Kris Jurka bo...@ejurka.com writes:
On Fri, 6 Aug 2010, James William Pye wrote:
I think there's a snag in the patch:
Oh, duh. It's a server side copy not going through the client at all.
Here's a hopefully final patch.
Applied with a correction: this would've totally broken binary copy in
On Aug 9, 2010, at 11:49 AM, Kris Jurka wrote:
Oh, duh. It's a server side copy not going through the client at all. Here's
a hopefully final patch.
Trying it out... Works for me.
I understand the resistance to the patch, but it would be
quite nice to see this wart in the rear view. =\
--
On Sat, 7 Aug 2010, Kris Jurka wrote:
On Fri, 6 Aug 2010, James William Pye wrote:
I think there's a snag in the patch:
postgres=# COPY data FROM '/Users/jwp/DATA.bcopy' WITH BINARY;
ERROR: row field count is -1, expected 1
CONTEXT: COPY data, line 4
Probably a quick/small fix away, I
On Fri, 6 Aug 2010, James William Pye wrote:
On Aug 6, 2010, at 4:31 PM, Kris Jurka wrote:
binary-copy-end-v2.patch
I think there's a snag in the patch:
postgres=# COPY data FROM '/Users/jwp/DATA.bcopy' WITH BINARY;
ERROR: row field count is -1, expected 1
CONTEXT: COPY data, line 4
On Wed, 28 Jul 2010, James William Pye wrote:
Not directly regarding your patch, but while the discussion is in the
general area. I think it would be wise to throw an error when non-empty
CopyData messages are received after CopyData(EOF). Chances are that the
user is making a mistake and
On Aug 6, 2010, at 4:31 PM, Kris Jurka wrote:
binary-copy-end-v2.patch
I think there's a snag in the patch:
postgres=# COPY data FROM '/Users/jwp/DATA.bcopy' WITH BINARY;
ERROR: row field count is -1, expected 1
CONTEXT: COPY data, line 4
Probably a quick/small fix away, I imagine.
But, I
(Yes, I know I'm not on the hackers list. Most interested parties should
get this directly anyway.)
Additionally the interface exposed by the JDBC driver lets the user
write arbitrary CopyData bytes to the server, so without parsing all of
that we don't know whether they've issued
On Jul 25, 2010, at 8:01 AM, Kris Jurka wrote:
The JDBC driver reads server messages for multiple reasons.
One of them is indeed to do early failure detection.
That's high quality. =)
Another is to pickup NoticeResponse messages to avoid a network buffer
deadlock.
That's a good catch. I
On Wed, 28 Jul 2010, James William Pye wrote:
hrm, I suppose a lazy way around that problem would be to suspend all
client messages(client_min_messages) during COPY IN. Tho, I guess one
would still have to contend with NotificationResponse, and
ParameterStatus..
Technically you won't
On Jul 28, 2010, at 9:53 AM, Kris Jurka wrote:
Technically you won't get NotificationResponse until transaction end, so you
don't need to worry about that mid copy.
Ah, thanks for noting that. It would appear my original reading of the async
section didn't get far enough beyond Frontends must
On Sat, 24 Jul 2010, James William Pye wrote:
On Jul 23, 2010, at 7:11 AM, Tom Lane wrote:
I can't help thinking that the JDBC driver must be being overly cute
if this breaks it ...
I was wondering the same thing when I first saw Kris' message. However,
iff I understand what JDBC is
On Jul 23, 2010, at 7:11 AM, Tom Lane wrote:
I can't help thinking that the JDBC driver must be being overly cute
if this breaks it ...
I was wondering the same thing when I first saw Kris' message. However, iff I
understand what JDBC is trying to achieve, I don't think I would call it
On Thu, 22 Jul 2010, Robert Haas wrote:
On Thu, Jul 22, 2010 at 5:34 PM, Kris Jurka bo...@ejurka.com wrote:
Attached is a patch to make the server continue to consume protocol data
until instructed to stop by the client in the same way as copying text data
to the server currently works.
Kris Jurka wrote:
I guess the obvious question is whether we shouldn't instead change
the docs to match the behavior. I suspect there's almost no chance
we'd consider back-patching a change of this type, since it is a clear
behavior change. And even if we did, there would still be people
Kris Jurka bo...@ejurka.com writes:
Attached is a patch to make the server continue to consume protocol data
until instructed to stop by the client in the same way as copying text
data to the server currently works.
I believe this is a misunderstanding of the protocol spec. The spec is
On Fri, Jul 23, 2010 at 9:32 AM, Andrew Dunstan and...@dunslane.net wrote:
Kris Jurka wrote:
I guess the obvious question is whether we shouldn't instead change
the docs to match the behavior. I suspect there's almost no chance
we'd consider back-patching a change of this type, since it is a
On 7/23/2010 6:40 AM, Tom Lane wrote:
Kris Jurkabo...@ejurka.com writes:
Attached is a patch to make the server continue to consume protocol data
until instructed to stop by the client in the same way as copying text
data to the server currently works.
I believe this is a misunderstanding of
Kris Jurka bo...@ejurka.com writes:
On 7/23/2010 6:40 AM, Tom Lane wrote:
I believe this is a misunderstanding of the protocol spec. The spec is
(intended to say that) we'll continue to accept data after reporting an
error, not that we will silently swallow an incorrect data stream and
not
On Fri, 23 Jul 2010, Tom Lane wrote:
Kris Jurka bo...@ejurka.com writes:
On 7/23/2010 6:40 AM, Tom Lane wrote:
I believe this is a misunderstanding of the protocol spec. The spec is
(intended to say that) we'll continue to accept data after reporting an
error, not that we will silently
Per discussion and investigation on the -jdbc list, the server appears to
violate the frontend/backend protocol when binary copy data is sent to the
server. Upon receiving the binary copy end of data marker (a -1 field
count), the server immediately responds with CommandComplete and
On Thu, Jul 22, 2010 at 5:34 PM, Kris Jurka bo...@ejurka.com wrote:
Per discussion and investigation on the -jdbc list, the server appears to
violate the frontend/backend protocol when binary copy data is sent to the
server. Upon receiving the binary copy end of data marker (a -1 field
21 matches
Mail list logo
