ERROR: read binary tuple: partial copy data row (SQLSTATE XXUUU) about replicator

[fabiog1901]

The error on CDC sink persists even after stopping the inserts, after a truncate table _cdc_sink.defaultdb_t;, and cancel and restart the CDC-changefeed job.

[bobvawter]

Might be a buffer underrun here: https://github.com/cockroachdb/cockroach/blob/a194629fa50dd681329e158f78a2f0988684595b/pkg/sql/copy.go#L474

Will pull on that thread.

[bobvawter]

Summary of findings:

• In https://github.com/jackc/pgx/blob/23b4656fc573dcecd8bdce9c0235249e73d384f4/copy_from.go#L187-L188 the buildCopyBuf function has a test to limit the size of the output buffer, but the generated buffer can still exceed 64k.
• When this buffer reaches https://github.com/jackc/pgconn/blob/53f5fed36c570f0b5c98d6ec2415658c7b9bd11c/pgconn.go#L1217-L1222 it gets sent as multiple wire messages. This means that a tuple can span multiple length-delimited chunks.
• The wire format https://www.postgresql.org/docs/current/protocol-message-formats.html allows for 32-bit message lengths in the copy protocol, but it also states that "messages sent by frontends may divide the data stream arbitrarily."
• CRDB's copy-in code https://github.com/cockroachdb/cockroach/blob/65abfccdf6b61495e0f262307e1c2d7d492ce55c/pkg/sql/copy.go#L251 assumes that a row's tuple values don't span wire messages, which appears to contravene the pgwire protocol.
• I can't find a test in CRDB that exercises the binary copy protocol with enough rows or large-enough values to trigger the protocol errors.
• If I patch pgconn.go to use an intermediate buffer with a larger capacity, my large-clob test passes.

[bobvawter]

Upstream fix is available in 21.1.9, so I'm going to roll this hack out of the codebase.