Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hgbqA-0003yR-J9 for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Jun 2019 21:21:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hgbq9-0006zJ-A2 for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Jun 2019 21:21:57 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hgbq8-0006z8-TX for pgsql-hackers@lists.postgresql.org; Thu, 27 Jun 2019 21:21:57 +0000 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hgbq5-0000eI-Gq for pgsql-hackers@postgresql.org; Thu, 27 Jun 2019 21:21:56 +0000 Received: by mail-qt1-x842.google.com with SMTP id d17so4092702qtj.8 for ; Thu, 27 Jun 2019 14:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=AeXLLOghPdUAUj93PUrbLq309yhSjRJzbMKHSPO2g08=; b=IcatadBF3E49RxeTGRLe4r+SWsUnKln2VaYunAqMPsqqnWPeiYW8lkmihKQrX8toZi wZJN6FCLku3Bul/F81qevG4Y8+oOorzGn0gKq5Eijjcm1Ls1w9B0t1xWVfcfN1n1rl6F zdD4ryWELnrvA/X6eQJShQLL2JoOJsjXb23XibaUqMqk4Rfl4/eaJ/5mILkjxYqKmMaF 5trwsjocwOCXzzmGyWmQYBQ2MG5AvmHVd6MnhVZRWJp9yUFWsAQ19Kx3v0+NTh09h8sp VEYPlG4VZyZXLw6tJ0fuq6eW5GDyZmjSt3fKuuEO569hqeXelLXroWmUMWjfIyVgfoKd 0bdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=AeXLLOghPdUAUj93PUrbLq309yhSjRJzbMKHSPO2g08=; b=kc5AGTqIAJfNnua5rIw419k8E7qB73wBtQI7OjfGNjVcEiKIknnMtAGGGFt0Nvz2VF uCp6Fv9DPuTXU84K0MOfFtrCmvLxxHYmbTShrrbqrDtQ2kjA2NDV8CnHpkih3isDV+lC uqS1G6tB12ggppLx/6rXhakBbk2XZNmdFcIVdMp7fuFuBmzKUZviizHWhv/w+aYdcmeO LqJQY/opseLRBF9Gne1ElkTEz1pYLbA92b24vv993ulEXcc6/qIQOPj8QS3Lx54z0PC6 CHHwgC/+877voEQBB31K4TYO+jJ05VpvyLbmVRrVHMHo6xC5FwXI81ZHoe86fg6IDP2U wyWg== X-Gm-Message-State: APjAAAVdR0ohfG84+M3IQpFPMnKrlWG1ASPNC/xJIcZpAcP0Kv5Bz8on PuyC8HyDJzqjscj9u5IRvdnNeQ== X-Google-Smtp-Source: APXvYqwP8zxEIAT0eiMG+GknMfGb6tQWOeGnPx5l9VKWrlXz6RxbELri97aLLp4h4dNNUihzUN1lEw== X-Received: by 2002:a0c:c782:: with SMTP id k2mr5159796qvj.53.1561670511636; Thu, 27 Jun 2019 14:21:51 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([190.121.29.3]) by smtp.gmail.com with ESMTPSA id l6sm124606qkf.83.2019.06.27.14.21.50 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Thu, 27 Jun 2019 14:21:50 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id 03126120718; Thu, 27 Jun 2019 17:21:49 -0400 (-04) Date: Thu, 27 Jun 2019 17:21:48 -0400 From: Alvaro Herrera To: Tom Lane Cc: Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: [HACKERS] Regression tests vs existing users in an installation Message-ID: <20190627212148.GA5801@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <27282.1561668606@sss.pgh.pa.us> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Jun-27, Tom Lane wrote: > Further on the rolenames test mess: I started to work on removing > that script's creation of out-of-spec user names, but my heart just > sank to the floor when I noticed that it was also doing stuff like > this: > > ALTER USER ALL SET application_name to 'SLAP'; > ALTER USER ALL RESET application_name; > > The extent to which that's Not OK inside a production installation > is hard to overstate. Uh-oh. I don't remember doing that, but evidently I did :-( > At the same time, I can see that we'd want to have some coverage > for that code path, so just deleting those tests isn't attractive. Yeah ... > What I propose that we do instead is invent an empty "module" under > src/test/modules/ and install rolenames as a test for that. Hmm, that's an idea, yes. > Now, this doesn't in itself fix the problem that my proposed patch will > emit warnings about the rolenames test script creating "Public" and so on. > We could fix that by maintaining a variant expected-file that includes > those warnings, but probably a less painful answer is just to jack > client_min_messages up to ERROR for that short segment of the test script. +1 > We could make the new subdirectory be something specific like > "src/test/modules/test_rolenames", but I think very likely we'll be > wanting some additional test scripts that we likewise deem unsafe to > run during "installcheck". So I'd rather choose a more generic module > name, but I'm not sure what ... "unsafe_tests"? +0 for unsafe_tests, -1 for test_rolenames. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services