Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UtgqF-0004wM-LQ for pgsql-admin@arkaria.postgresql.org; Mon, 01 Jul 2013 16:20:39 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1UtgqE-0000Z5-3U for pgsql-admin@arkaria.postgresql.org; Mon, 01 Jul 2013 16:20:38 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Utgq5-0000Mk-UR for pgsql-admin@postgresql.org; Mon, 01 Jul 2013 16:20:30 +0000 Received: from smtprelay0144.b.hostedemail.com ([64.98.42.144] helo=smtprelay.b.hostedemail.com) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Utgq1-0003Gb-9n for pgsql-admin@postgresql.org; Mon, 01 Jul 2013 16:20:29 +0000 Received: from filter.hostedemail.com (b-bigip1 [10.5.19.254]) by smtprelay04.b.hostedemail.com (Postfix) with ESMTP id DBB7E7B864; Mon, 1 Jul 2013 16:20:23 +0000 (UTC) X-Session-Marker: 616C76686572726540616C76682E6E6F2D69702E6F7267 X-Panda: scanned! X-Spam-Summary: 50, 0, 0, , d41d8cd98f00b204, alvherre@alvh.no-ip.org, :::, RULES_HIT:152:355:379:599:967:973:982:988:989:1260:1277:1311:1312:1313:1314:1345:1359:1437:1513:1515:1516:1518:1519:1521:1534:1541:1593:1594:1595:1596:1711:1730:1747:1777:1792:2393:2525:2560:2563:2682:2685:2859:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3353:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4416:4605:4659:5007:6261:7875:9025:9040:9121:10004:10400:10848:11232:11256:11257:11658:11914:12517:12519:12555:13069:13311:13357:13870:13895, 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:0:0 X-HE-Tag: paint02_5aabd5e66844b X-Filterd-Recvd-Size: 2457 Received: from eldon.alvh.no-ip.org (unknown [200.126.64.69]) (Authenticated sender: alvherre@alvh.no-ip.org) by omf07.b.hostedemail.com (Postfix) with ESMTPA; Mon, 1 Jul 2013 16:20:23 +0000 (UTC) Received: by eldon.alvh.no-ip.org (Postfix, from userid 1000) id 3B9161FC5; Mon, 1 Jul 2013 12:20:21 -0400 (CLT) Date: Mon, 1 Jul 2013 12:20:21 -0400 From: Alvaro Herrera To: "Wojciechowski, Robert (GE Transportation)" Cc: "pgsql-admin@postgresql.org" Subject: Re: How was I able to drop a role even though objects depend on it? Message-ID: <20130701162021.GE3757@eldon.alvh.no-ip.org> References: <59BF48FAC524384DA413D8F4F2E4BA6907D9A9DA@CINURCNA06.e2k.ad.ge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <59BF48FAC524384DA413D8F4F2E4BA6907D9A9DA@CINURCNA06.e2k.ad.ge.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org Wojciechowski, Robert (GE Transportation) wrote: > I=E2=80=99ve noticed a weird situation on one of our development servers = running PostgreSQL 9.1.3 where roles have been dropped even though objects = depend on that user. I didn=E2=80=99t think that was possible due to the de= pendency checks on DROP USER/ROLE. For example, there is a database that sh= ows this connect grant to a user that was known as foo1_userA (oid 35623395= 47): 3562339547=3Dc/postgres This happened after a nightly database import = script was run that takes in new clone databases from production. After the= script imports new databases another script runs that drop all users match= ing a regex (/^foo1_user/ for example) to clear out stale users. This obvio= usly should succeed dropping a user that does not have dependent objects an= d should fail on users that do. For some this is not holding true. Is this = a bug? Am I relying too much on DROP USER/ROLE? Any alternative approaches = to clearing out users that do not have dependent objects or guidance on deb= ugging this situation would be much appreciated! -- Robert It sounds like a bug to me. Can you provide a self-contained reproducer of this? It'd be useful to know what kind of objects (should have) depended on that user, for instance. --=20 =C3=81lvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services --=20 Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin