> 2021年3月28日 21:07，Andrew Dunstan <and...@dunslane.net> 写道： > > > 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. You're right, it doesn't look good. I'll organize them and put them in place.
Wenjing. > > > cheers > > > andrew > > > -- > > Andrew Dunstan > EDB: https://www.enterprisedb.com > > <global_temporary_table_v44-pg14.patch.gz>
smime.p7s
Description: S/MIME cryptographic signature
