Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t8OBd-003sjH-VD for pgsql-general@arkaria.postgresql.org; Tue, 05 Nov 2024 18:21:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1t8OBb-00H2wq-CH for pgsql-general@arkaria.postgresql.org; Tue, 05 Nov 2024 18:21:51 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1t8OBb-00H2wh-1g for pgsql-general@lists.postgresql.org; Tue, 05 Nov 2024 18:21:51 +0000 Received: from mail-ot1-x32c.google.com ([2607:f8b0:4864:20::32c]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t8OBX-000NBW-BF for pgsql-general@lists.postgresql.org; Tue, 05 Nov 2024 18:21:51 +0000 Received: by mail-ot1-x32c.google.com with SMTP id 46e09a7af769-71815313303so2826844a34.1 for ; Tue, 05 Nov 2024 10:21:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1730830906; x=1731435706; darn=lists.postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=6oOD1PyWLSoHW49FDLcT62NB0n7IiYQvPH1d1lM5dYE=; b=i8pJqLlAdhLd7HLX6EzOkD+Y7kaoEX5n3Yjn4FrmtrsWVLrfFCGBNXj5Dzm4Ql6Tb9 DWOlz8fe7FpEsj+78O7Q2nPfBmcL4sGvnlQZPuP1jwKttH0FcSU02Qi7FQqhU079r+Fk KD3fpQKGTFhY0HstcpzUAbHlCYnZTUrIJoSLAMLaa5zmN0UBM/8D4CnRXCMDudhdItlH EJPIuCPijhMMCiTOreb3/dDAXy8KwdUxk3uCS1sxEoomZMRbDw/+eBrupKmuc2EA16Dj wGHx+hiJSxxuDR5ib7t5otIZK/DYSYymRP7MIw/DgwjzKRCdcZ+6x5ZHNcw5GOwYFRE2 OL6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730830906; x=1731435706; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=6oOD1PyWLSoHW49FDLcT62NB0n7IiYQvPH1d1lM5dYE=; b=DrPnDV6Ink/1wQEbh4TXllzPczlCOrwYAWs9sqD430Cfoz37TwtuA7yRlzwS+OztDr vM4Dka/nmLWnhab7NQLwYs00BRSKgYNOUGh2n1gh5j7bGtMn1CR9Iy5FnYnadcbpM0p/ BHHeIzhqX/dOPc+X/rWt3ucgJUiGxKLwgYGK3AiwrjFfsQUFwiBj1McCHzsCQXZs8Z7k LOg9FWX4+/Ot5UzzICz8NUYyMJy6PFRsbFkntIb5pBM2/A5FiIX7snirUUwlBc+0TWs0 aFlxmnYMBJddEvngrzKUZQ87kw6x2RjP4LrPxUNGNrR7jWM2sFT9sgLAn8Lxtu9WDH4L 9NKw== X-Gm-Message-State: AOJu0YxO3GIIikE/l1QWo7KD2+pQZqLpclF92lXPNgCL0O7BCbWd7r0x TqzDmVdmPnurmchpB1t9wSw1urk2bgFRFBQ+lN1MwLJh74c1oR6h+63ATjI3185d3ARKGtutYHw 1qweq/rMrZfQ1PYvTkg02a9fXDcg= X-Google-Smtp-Source: AGHT+IF6L+DlHBuXRpfRYi/fxgRxlsioUTAKIBSrLHCEBEbIL8eWRGZNVce2DwNrnirE81GknDs8tyvlbx2qeSMEHZA= X-Received: by 2002:a05:6830:3693:b0:710:dab2:684 with SMTP id 46e09a7af769-71868285f37mr39727850a34.25.1730830906257; Tue, 05 Nov 2024 10:21:46 -0800 (PST) MIME-Version: 1.0 References: <3070156.1730828552@sss.pgh.pa.us> In-Reply-To: <3070156.1730828552@sss.pgh.pa.us> From: Dominique Devienne Date: Tue, 5 Nov 2024 19:21:35 +0100 Message-ID: Subject: Re: Switching to NOINHERIT user triggers #XX000 error To: Tom Lane Cc: pgsql-general@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Nov 5, 2024 at 6:42=E2=80=AFPM Tom Lane wrote: > Dominique Devienne writes: > > On v16 and v17 though, it works with INHERIT, but with NOINHERIT, I get= : > > GRANT "...:USER" TO "ddevienne" #XX000: ERROR: no possible grantors > > Any clue to what this means, so I can start looking in the right place? > > \errverbose in psql would help you locate what part of the code > is throwing that. (Or if triggering it from psql is not convenient, > set log_error_verbosity =3D verbose and find the info in the postmaster > log.) > > This is probably a bug, at least to the extent that we don't like > XX000 errors to be easily reachable, so please let us know what > you find out. Hi Tom. Finding where the error is thrown is easy, it's when I'm doing that grant. But the code creates two larguish schemas before that and several ROLEs, so it's not easy to share. I trapped the error in the code, and here's the details ERROR: XX000: no possible grantors LOCATION: check_role_grantor, user.c:2229 I used PQresultVerboseErrorMessage(). Tell me if you need some other error field This is against a 17.0 server, for the line number above. If I shared (privately) a libpq client-side trace with you Tom, would that help you? This particular test, I could redesign to work-around this issue probably. But this is not the only tests that fails with a NOINHERIT user on v16+, and I haven't tracked down all the reasons yet... PS: I can't easily get server-side logs