Re: [Proposal] Global temporary tables - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: [Proposal] Global temporary tables
Date
Msg-id CAFj8pRBQ7fiX5tvYgJjSS8K_RhkDkXkvdiY1j9=qW1XCz63kDA@mail.gmail.com
Whole thread Raw
In response to Re: [Proposal] Global temporary tables  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: [Proposal] Global temporary tables
Re: [Proposal] Global temporary tables
List pgsql-hackers


ne 28. 3. 2021 v 15:07 odesílatel Andrew Dunstan <andrew@dunslane.net> napsal:

On 3/17/21 7:59 AM, wenjing wrote:
> ok
>
> The cause of the problem is that the name of the dependent function
> (readNextTransactionID) has changed. I fixed it.
>
> This patch(V43) is base on 9fd2952cf4920d563e9cea51634c5b364d57f71a
>
> Wenjing
>
>

I have fixed this patch so that

a) it applies cleanly

b) it uses project best practice for catalog Oid assignment.

However, as noted elsewhere it fails the recovery TAP test.

I also note this:


diff --git a/src/test/regress/parallel_schedule
b/src/test/regress/parallel_schedule
index 312c11a4bd..d44fa62f4e 100644
--- a/src/test/regress/parallel_schedule
+++ b/src/test/regress/parallel_schedule
@@ -129,3 +129,10 @@ test: fast_default
 
 # run stats by itself because its delay may be insufficient under heavy
load
 test: stats
+
+# global temp table test
+test: gtt_stats
+test: gtt_function
+test: gtt_prepare
+test: gtt_parallel_1 gtt_parallel_2
+test: gtt_clean


Tests that need to run in parallel should use either the isolation
tester framework (which is explicitly for testing things concurrently)
or the TAP test framework.

Adding six test files to the regression test suite for this one feature
is not a good idea. You should have one regression test script ideally,
and it should be added as appropriate to both the parallel and serial
schedules (and not at the end). Any further tests should be added using
the other frameworks mentioned.


* bad name of GTT-README - the convention is README.gtt

* Typo - "ofa"

2) Use beforeshmemexit to ensure that all files ofa session GTT are deleted when
the session exits.

* Typo "nd"

3) GTT storage file cleanup during abnormal situations
When a backend exits abnormally (such as oom kill), the startup process starts
recovery before accepting client connection. The same startup process checks
nd removes all GTT files before redo WAL.

* This comment is wrong

  /*
+ * Global temporary table is allowed to be dropped only when the
+ * current session is using it.
+ */
+ if (RELATION_IS_GLOBAL_TEMP(rel))
+ {
+ if (is_other_backend_use_gtt(RelationGetRelid(rel)))
+ ereport(ERROR,
+ (errcode(ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST),
+ errmsg("cannot drop global temporary table %s when other backend attached it.",
+ RelationGetRelationName(rel))));
+ }

* same wrong comment

  /*
+ * Global temporary table is allowed to be dropped only when the
+ * current session is using it.
+ */
+ if (RELATION_IS_GLOBAL_TEMP(rel))
+ {
+ if (is_other_backend_use_gtt(RelationGetRelid(rel)))
+ ereport(ERROR,
+ (errcode(ERRCODE_DEPENDENT_OBJECTS_STILL_EXIST),
+ errmsg("cannot drop global temporary table %s when other backend attached it.",
+ RelationGetRelationName(rel))));
+ }

* typo "backand"

+/*
+ * Check if there are other backends using this GTT besides the current backand.
+ */

There is not user's documentation

Regards

Pavel

 

cheers


andrew


--

Andrew Dunstan
EDB: https://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: invalid data in file backup_label problem on windows
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Walsender may fail to send wal to the end.