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 1tiday-000e29-OH for pgsql-general@arkaria.postgresql.org; Thu, 13 Feb 2025 18:05: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 1tidaw-00BymC-Py for pgsql-general@arkaria.postgresql.org; Thu, 13 Feb 2025 18:05: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 1tidav-00BylY-TP for pgsql-general@lists.postgresql.org; Thu, 13 Feb 2025 18:05:51 +0000 Received: from fout-b7-smtp.messagingengine.com ([202.12.124.150]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tidat-000ekF-1T for pgsql-general@lists.postgresql.org; Thu, 13 Feb 2025 18:05:50 +0000 Received: from phl-compute-04.internal (phl-compute-04.phl.internal [10.202.2.44]) by mailfout.stl.internal (Postfix) with ESMTP id 17801114017A; Thu, 13 Feb 2025 13:05:46 -0500 (EST) Received: from phl-mailfrontend-01 ([10.202.2.162]) by phl-compute-04.internal (MEProxy); Thu, 13 Feb 2025 13:05:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aklaver.com; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm2; t=1739469945; x=1739556345; bh=1IpEmBqkBeV/f0a7SQnGy/SbFJvbcctTeEJ1vzMMrSo=; b= oim/DJGt3LznJ3uvXC8d9qw1eYLhLbtTACke87pAQNzPywHHCOu9cwTqvpfbNqhp 3gfDQ3j2zagorcuMd45IemStBEcmLLvvU2Yk+rW9SRW6SuE+DQ0inJpeoCp2NDx8 VZsk1YDuwnP9AU3KnvoUcAMfhAfhcNh1AfGoxUwNW7GtkmDhOBih2CNqpXe9LBhy FutH/6uKKa7f3Num3m5+1TOPC0MXpGeTce92hsipuUkZFiZLU3Id/YK+TMUapNz4 SpB1IADfc0AufqLlUQdBVF/05QaDCtUzVyJl4HCXQKj2SxpuUezomyDgBNVnLtcw GJqheuSvP4sPOIi2pG05nA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1739469945; x= 1739556345; bh=1IpEmBqkBeV/f0a7SQnGy/SbFJvbcctTeEJ1vzMMrSo=; b=U uO4emHiQAxVWj9dOm8e5hqH6Pc7OKgUnBTmiAGdIL1QSLIvX68b4OHpcQcqRxNR4 J4H2p/YnNd3Geq4rG+fF0ekBdMMh0DRyjxeDkxWSMYyelp5/U+KISNj/9CFfU4NJ h27R9SuVCKOUFqGpwtrP8PIEg2O/mIAxSIR5tlFLmAjfJFHdWhT4L3UEPiGMUNQf HdLBOslnJ4x58OXbSwz4xlhXaIXsEnUlZCiwr+9LqHuSnCirFZ0y8yZSZFKdZedS JP+VcVpPFxqBMcJQc/oX1HF4rs7XHUAcQoyCDaAU5HG6Zc8WTD2C0mR4sUMM52uN AzIHPpGS7zdR8+y6MgWpA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgdegjeeggecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthekredttddv jeenucfhrhhomheptegurhhirghnucfmlhgrvhgvrhcuoegrughrihgrnhdrkhhlrghvvg hrsegrkhhlrghvvghrrdgtohhmqeenucggtffrrghtthgvrhhnpefgudefkefhveefleev ieeuveehvdduudekuddvvdelhfeuueeijedtuedvvedvueenucffohhmrghinhepphhosh htghhrvghsqhhlrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomheprggurhhirghnrdhklhgrvhgvrhesrghklhgrvhgvrhdrtghomhdpnh gspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhrtghpthhtohepphgruhhl rdhfohgvrhhsthgvrhesghhmrghilhdrtghomhdprhgtphhtthhopehpghhsqhhlqdhgvg hnvghrrghlsehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-ME-Proxy: Feedback-ID: i76984098:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 13 Feb 2025 13:05:44 -0500 (EST) Message-ID: <159fd473-e361-4b60-9d62-5cf617bc4be1@aklaver.com> Date: Thu, 13 Feb 2025 10:05:44 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: libc to libicu via pg_dump/pg_restore? To: Paul Foerster Cc: pgsql-general list References: <187f2c5d-f268-4596-bb63-c94790ae761d@aklaver.com> <99d51fe7-c6d2-4421-9456-07ed1f5703a2@aklaver.com> <5A9148A0-CF9C-4841-A9C0-D7E299AC4ADD@gmail.com> <0150a3d8-9276-4534-9847-8d3d7bba6e16@aklaver.com> Content-Language: en-US From: Adrian Klaver In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2/13/25 09:31, Paul Foerster wrote: > Hi Adrian, > >> On 13 Feb 2025, at 17:40, Adrian Klaver wrote: >> >> Per: >> >> https://www.postgresql.org/docs/current/ddl-priv.html >> >> "If the “Access privileges” column is empty for a given object, it means the object has default privileges (that is, its privileges entry in the relevant system catalog is null). Default privileges always include all privileges for the owner, and can include some privileges for PUBLIC depending on the object type, as explained above. The first GRANT or REVOKE on an object will instantiate the default privileges (producing, for example, miriam=arwdDxt/miriam) and then modify them per the specified request. Similarly, entries are shown in “Column privileges” only for columns with nondefault privileges. (Note: for this purpose, “default privileges” always means the built-in default privileges for the object's type. An object whose privileges have been affected by an ALTER DEFAULT PRIVILEGES command will always be shown with an explicit privilege entry that includes the effects of the ALTER.)" >> >> From this: >> >> 1) It not unusual for the field to be blank. >> >> 2) \l only lists the privileges for the database object itself, not any of it's contained objects. >> >> In the original database are you executing explicit GRANTs on the database object? >> >> Do: >> >> pg_restore -s -f db_name.sql ${PGDATABASE}.out >> >> This will create a text version restore of the schema objects in the dump file. Then search the file for GRANT statements. > > ${PGDATABASE}.out and ${PGDATABASE}.err are just log files of the backgrounded pg_dump command. The .out file is empty anyway and the .err file only contains the messages about the database being not be able to be dropped (-c) because I sit on it, which is explainable and correct. Then run pg_restore -s -f db_name.sql against whatever is the dump file produced by pg_dump -Fc -Z1 ... It will create a plain text version of the schema definitions, no data in the file db_name.sql. Then you can see if GRANTs are being done. > > What I mean is, in our environment there are four (application) roles having certain privileges, one of them being the database owner while the others have certain rights like reading or manipulating data, but no DDL. These four roles all have their privileges shown with \l in the access privileges column. Contrary to how I understand the documentation of pg_restore, they are restored only if I use -cC and they are not restored if I only use -C. From here: https://www.postgresql.org/docs/current/app-psql.html \l[+] or \list[+] [ pattern ] List the databases in the server and show their names, owners, character set encodings, and access privileges. If pattern is specified, only databases whose names match the pattern are listed. If + is appended to the command name, database sizes, default tablespaces, and descriptions are also displayed. (Size information is only available for databases that the current user can connect to.) This only shows the information the actual database object not the objects contained within it. You will need to show your work: 1) What does \l show in the cluster you are dumping from? 2) What are the roles and what privileges are they being granted? > > Cheers, > Paul -- Adrian Klaver adrian.klaver@aklaver.com