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).
---
