I read through this.
Find attached some language fixes. You should be able to apply each "fix"
patch on top of your own local branch with git am, and then squish them
together. Let me know if you have trouble with that.
I think get_seqence_start_value() should be static. (Or otherwise, it should
be in lsyscache.c).
The include added to execPartition.c seems to be unused.
+#define RELATION_IS_TEMP_ON_CURRENT_SESSION(relation) \
+#define RELATION_IS_TEMP(relation) \
+#define RelpersistenceTsTemp(relpersistence) \
+#define RELATION_GTT_ON_COMMIT_DELETE(relation) \
=> These macros can evaluate their arguments multiple times.
You should add a comment to warn about that. And maybe avoid passing them a
function argument, like: RelpersistenceTsTemp(get_rel_persistence(rte->relid))
+list_all_backend_gtt_frozenxids should return TransactionId not int.
The function name should say "oldest" and not "all" ?
I think the GUC should have a longer name. max_active_gtt is too short for a
global var.
+#define MIN_NUM_ACTIVE_GTT 0
+#define DEFAULT_NUM_ACTIVE_GTT 1000
+#define MAX_NUM_ACTIVE_GTT 1000000
+int max_active_gtt = MIN_NUM_ACTIVE_GTT
It's being initialized to MIN, but then the GUC machinery sets it to DEFAULT.
By convention, it should be initialized to default.
fout->remoteVersion >= 140000
=> should say 15
describe.c has gettext_noop("session"), which is a half-truth. The data is
per-session but the table definition is persistent..
You redirect stats from pg_class and pg_statistics to a local hash table.
This is pretty hairy :(
I guess you'd also need to handle pg_statistic_ext and ext_data.
pg_stats doesn't work, since the data isn't in pg_statistic - it'd need to look
at pg_get_gtt_statistics.
I wonder if there's a better way to do it, like updating pg_statistic but
forcing the changes to be rolled back when the session ends... But I think
that would make longrunning sessions behave badly, the same as "longrunning
transactions".
Have you looked at Gilles Darold's GTT extension ?
