Provide workaround to reclaim space on truncate cmd in sub-transaction
As discussed in gpdb-users thread [1], currently no mechanism exist to reclaim disk space for a table created and truncated or dropped iteratively in a plpython function. PostgreSQL 11 provides `plpy.commit()` using which this can be achieved. But in absence of same need to provide some mechanism as MADlib has requirement for this functionality for GPDB6 and forward. Hence, considering the requirement as interim work-around adding guc to be able to perform unsafe truncate instead of safe truncate from plpython execute function. Setting the GUC can force unsafe truncation only if - inside sub-transaction and not in top transaction - table was created somewhere within this transactions scope and not outside of it The GUC will be set in the plpython udf and if any `plpy.execute()` errors out the top transaction will also rollback. The GUC can't be set in postgresql.conf file. Also, added description to warn the guc is not for general purpose use and is developer only guc. Added test showcases in simple form the scenario. [1] https://groups.google.com/a/greenplum.org/d/msg/gpdb-users/YCtI4oUA3r0/t0CzhtL6AQAJReviewed-by: NSoumyadeep Chakraborty <sochakraborty@pivotal.io>
Showing
想要评论请 注册 或 登录