Kris Jurka 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
old-style
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 im
On Fri, 6 Aug 2010, James William Pye wrote:
On Aug 6, 2010, at 4:31 PM, Kris Jurka 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
On Aug 6, 2010, at 4:31 PM, Kris Jurka 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 imagine.
But, I was able to trigger the
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 sh
(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 CopyData(EOF
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 mu
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 get
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.
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 trying
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
"over
On Fri, 23 Jul 2010, Tom Lane wrote:
Kris Jurka 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
Kris Jurka 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 complain
On 7/23/2010 6:40 AM, Tom Lane wrote:
Kris Jurka 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 spe
On Fri, Jul 23, 2010 at 9:32 AM, Andrew Dunstan 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 clear
>
Kris Jurka 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
(intended to say t
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
runni
On Thu, 22 Jul 2010, Robert Haas wrote:
On Thu, Jul 22, 2010 at 5:34 PM, Kris Jurka 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.
I guess the obvio
On Thu, Jul 22, 2010 at 5:34 PM, Kris Jurka 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
> count), the server
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
ReadyFor
21 matches
Mail list logo
