On Tue, Jun 07, 2016 at 10:24:33PM +0000, Clément Prévost wrote: > I also considered setting max_parallel_degree to 1 to make the test more > futur-proof but there is a rather long discussion on the setting name ( > https://www.postgresql.org/message-id/20160424035859.gb29...@momjian.us) so > I can't decide on my own if it's worth the explicit dependency.
It wouldn't be a problem to update this test when renaming the setting, but I didn't see an impending need to use that setting. > > As of today, "make installcheck" passes with > > "default_transaction_isolation = > > serializable" in postgresql.conf. Let's preserve that property. You could > > wrap the parallel queries in "begin isolation level repeatable read;" > > ... "commit;", or you could SET default_transaction_isolation itself. > > > > I did add the transaction, but I don't get why this specific test should > use this specific transaction isolation level. We disable all parallelism at serializable isolation. Any other isolation level would have worked; repeatable read was an arbitrary choice. I added a comment to that effect. > -test: select_into select_distinct select_distinct_on select_implicit > select_having subselect union case join aggregates transactions random > portals arrays btree_index hash_index update namespace prepared_xacts delete > +test: select_into select_distinct select_distinct_on select_implicit > select_having subselect union case join aggregates transactions random > portals arrays btree_index hash_index update namespace prepared_xacts delete > select_parallel I moved the test to a different group, in light of this parallel_schedule header comment: # By convention, we put no more than twenty tests in any one parallel group; # this limits the number of connections needed to run the tests. > + exception > + -- raise custom exception, the original message contains > + -- a worker PID that must be hidden in the test output > + when others then raise exception 'Error in worker'; I changed this to keep the main message while overwriting the CONTEXT; a bug in this area could very well produce some other error rather than no error. Committed that way. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
