Hello,
there is incorrect signed/unsigned integer conversion in cstore_clean_table_resources() function. Once the Oid goes over 2^31 -1, cstore files aren't deleted and become unreachable by postgres. In the other words, DROP FOREIGN TABLE statement won't free any data on disk. All of this happens in silence without any notice in logs - I understand why there is no logging of missing files, but it makes the issue even more serious since it starts happening in random point in time (from the perspective of user).
This issue caused me non-trivial problems on version 1.7.0. I hope for quick fix in main repository so others can be saved from hours of debugging.
This is the patch I'm currently using in my deployments:
diff --git a/cstore_fdw.c b/cstore_fdw.c
index 7bfac28..ed08a63 100644
--- a/cstore_fdw.c
+++ b/cstore_fdw.c
@@ -1356,8 +1356,8 @@ cstore_clean_table_resources(PG_FUNCTION_ARGS)
struct stat fileStat;
int statResult = -1;
- appendStringInfo(filePath, "%s/%s/%d/%d", DataDir, CSTORE_FDW_NAME,
- (int) MyDatabaseId, (int) relationId);
+ appendStringInfo(filePath, "%s/%s/%u/%u", DataDir, CSTORE_FDW_NAME,
+ MyDatabaseId, relationId);
/*
* Check to see if the file exist first. This is the only way to
Cheers,
MM
Hello,
there is incorrect signed/unsigned integer conversion in
cstore_clean_table_resources()function. Once the Oid goes over 2^31 -1, cstore files aren't deleted and become unreachable by postgres. In the other words,DROP FOREIGN TABLEstatement won't free any data on disk. All of this happens in silence without any notice in logs - I understand why there is no logging of missing files, but it makes the issue even more serious since it starts happening in random point in time (from the perspective of user).This issue caused me non-trivial problems on version 1.7.0. I hope for quick fix in main repository so others can be saved from hours of debugging.
This is the patch I'm currently using in my deployments:
Cheers,
MM