Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bOGiO-0005ck-FA for pgsql-hackers@arkaria.postgresql.org; Sat, 16 Jul 2016 03:56:32 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bOGiM-0004uv-Qo for pgsql-hackers@arkaria.postgresql.org; Sat, 16 Jul 2016 03:56:30 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bOGh0-0003MQ-Nh for pgsql-hackers@postgresql.org; Sat, 16 Jul 2016 03:55:06 +0000 Received: from smtprelay0010.b.hostedemail.com ([64.98.42.10] helo=smtprelay.b.hostedemail.com) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bOGgx-0000sD-4E for pgsql-hackers@postgresql.org; Sat, 16 Jul 2016 03:55:05 +0000 Received: from filter.hostedemail.com (10.5.19.248.rfc1918.com [10.5.19.248]) by smtprelay05.b.hostedemail.com (Postfix) with ESMTP id 0D5FB32AC14; Sat, 16 Jul 2016 03:55:02 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Spam-Summary: 30,2,0,,d41d8cd98f00b204,alvherre@alvh.no-ip.org,:::,RULES_HIT:41:355:379:599:967:973:988:989:1260:1263:1277:1311:1312:1313:1314:1345:1359:1437:1515:1516:1518:1519:1534:1542:1593:1594:1595:1596:1711:1730:1747:1777:1792:2194:2199:2393:2525:2560:2563:2682:2685:2691:2828:2859:2899:2915:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3355:3865:3866:3867:3868:3870:3871:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4605:4659:5007:6119:6261:7901:7903:8957:9025:9121:9389:10010:10394:10400:10848:11232:11256:11257:11658:11914:12050:12517:12519:12663:13161:13229:13439:13894:13895:14181:14721:21080:21324:21433:30006:30030:30034:30051:30054:30070:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:1:0,LFtime:2,LUA_SUMMARY:none X-HE-Tag: money73_2bd3f7b4e3857 X-Filterd-Recvd-Size: 3529 Received: from alvin.alvh.no-ip.org (unknown [181.42.38.40]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf04.b.hostedemail.com (Postfix) with ESMTPA; Sat, 16 Jul 2016 03:55:01 +0000 (UTC) Received: by alvin.alvh.no-ip.org (Postfix, from userid 1000) id BC6D559D; Fri, 15 Jul 2016 23:54:56 -0400 (CLT) Date: Fri, 15 Jul 2016 23:54:56 -0400 From: Alvaro Herrera To: Tom Lane Cc: pgsql-hackers@postgreSQL.org Subject: Re: Regression tests vs existing users in an installation Message-ID: <20160716035456.GA181422@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <16638.1468620817@sss.pgh.pa.us> User-Agent: Mutt/1.5.23 (2014-03-12) X-Pg-Spam-Score: -0.4 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Tom Lane wrote: > We've talked before about how the regression tests should be circumspect > about what role names they create/drop, so as to avoid possibly blowing > up an installation's existing users during "make installcheck". In > particular I believe there was consensus that such names should begin > with, or at least include, "regress". I got around today to instrumenting > CreateRole to see what names we were actually creating, and was quite > depressed as to how thoroughly that guideline is being ignored (see > attached). > > I propose to go through the regression tests and fix this (in HEAD only). I would propose that we have one test run near the beginning or right at the beginning of the serial schedule that sets up a small number of roles to cover most of the needs of every other test, so that most such other tests do not need to create any roles at all. (Of course, there would be a few cases where this would defeat the purpose of the test because creating or dropping the role is precisely what is being created; those cases would have additional roles, with the proposed prefix.) So currently we have 97 roles? Probably we can get away with a dozen or so, maybe even less than that. > What I'm inclined to do with this is to reduce the test to be something > like > > BEGIN; > CREATE ROLE "Public"; > CREATE ROLE "None"; > CREATE ROLE "current_user"; > CREATE ROLE "session_user"; > CREATE ROLE "user"; > ROLLBACK; > > with maybe a couple of ALTERs and GRANTs inside the transaction to verify > that the names can be referenced as well as created. This would be safe > against modifying any conflicting existing users; the only bad consequence > would be a phony failure of the test. > > I thought about trying to preserve all the existing test cases while still > keeping these roles inside a transaction, by inserting savepoints around > the intentional failures. But there are enough intentional failures in > rolenames.sql that that would be really tedious. The existing test cases > seem enormously duplicative to me anyway, so I think a fairly short > transaction with a few tests would be sufficient to cover this territory. > A more aggressive answer would be to decide we don't need these test cases > at all and drop them. Hmm ... I think a blanket removal would go against generally accepted principle that our tests need to cover more functionality. Maybe we did go overboard on that one and the rolled-back creation is enough test for that functionality. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers