Re: PGCopyOutputStream close() v. endCopy()

Rob Sargent <[email protected]> Fri, 11 Jan 2019 10:07:19 -0700
Newsgroups gmane.comp.db.postgresql.jdbc
Message-ID <[email protected]>
Thanks you, very much.

I'll revert to using close() (even though the try-with will also as it 
make me more comfortable).

On 1/11/19 6:36 AM, Sehrope Sarkuni wrote:
> You're getting that error because endCopy() is being called twice. 
> Once by you explicitly in deliverSegments() and again when the 
> PGCopyOutputStream gets automatically closed by the 
> try-with-resources: 
> https://github.com/pgjdbc/pgjdbc/blob/master/pgjdbc/src/main/java/org/postgresql/copy/PGCopyOutputStream.java#L98-L112
>
> PGCopyOutputStream is a wrapper CopyIn (write to OutputStream => COPY 
> TO STDIN) that adds some buffering. You shouldn't be calling endCopy() 
> on it.
>
> You can either:
>
> 1. Remove the PGCopyOutputStream.endCopy() entirely as close() will 
> handle it. If do not need the final row count then you're done.
> 2. Use CopyIn directly, manage the buffer yourself, and call endCopy() 
> on it.
> 3. Manually manage the resources for PGCopyOutputStream so you can 
> reference it for getHandledRowCount() after the close().
> 4. Call close() instead of endCopy() on PGCopyOutputStream as it 
> handles being invoked more than once (it's a no-op for subsequent 
> close() calls).
>
> I'm going to take a look why PGCopyOutputStream.endCopy() is declared 
> public as currently there's no way to call both it and close() without 
> getting an error, and you're definitely supposed to call close(). 
> Either it should not be public or it should be performing the same 
> work as close(), i.e. clearing the internal "op" (copy operation) 
> member to indicate that the close is complete so subsequent close() 
> calls are not errant.
>
> Regards,
> -- Sehrope Sarkuni
> Founder & CEO | JackDB, Inc. | https://www.jackdb.com/