Github user sansanichfb commented on the issue: https://github.com/apache/incubator-hawq/pull/1353 @kapustor we can't fail safely when something wrong happens with at least one fragment, without dealing with the complexity of distributed transactions. So transaction handling doesn't look necessary in this PR. I would recommend to clearly state in the documents, that JDBC plugin doesn't guarantee a consistent outcome. Furthermore, we should set clear expectations for users and ask them to use staging tables for inserting data from Greenplum. It would allow us to simplify code and get rid of cumbersome rollback logic. WRT: > As for sending all the data in one batch - as I understand, such approach will limit the max data size by memory available for PXF service, because PXF have to aggregate the batch in its memory. - this is not exactly accurate since PXF is designed to be a lightweight layer between external storage and consumer thus no aggregation in memory is needed(except some reasonable buffering, depending on I/O and network sockets).
---