pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedInconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
26+ messages / 7 participants
[nested] [flat]
Commits from this thread:
2021-10-22 2acc84c6fd 3ad2c2455b b1df061f70 52b927a731 871dfe4b72 10f9faf6d8 4760060235 pg_dump: fix mis-dumping of non-global default privileges.
Related threads (commitfest entry pg_dump handling of ALTER DEFAULT PRIVILEGES IN SCHEMA/3288):
pg_dump handling of ALTER DEFAULT PRIVILEGES IN SCHEMA
* Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-03-24 20:38 Boris P. Korzun <drtr0jan@yandex.ru>
0 siblings, 0 replies; 26+ messages in thread
From: Boris P. Korzun @ 2021-03-24 20:38 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
------==--bound.1064580.iva5-4e96f110c519.qloud-c.yandex.net
Content-Transfer-Encoding: base64
Content-Type: text/html; charset=utf-8
PGRpdj5IaSw8L2Rpdj48ZGl2PjxkaXY+wqA8L2Rpdj48ZGl2PjxkaXY+UG9zdGdyZVNRTCB2ZXJz
aW9uOiAxMy4yPC9kaXY+PGRpdj5PcGVyYXRpbmcgc3lzdGVtOiDCoEZyZWVCU0QgMTMtU1RBQkxF
PC9kaXY+PGRpdj7CoDwvZGl2PjwvZGl2PjxkaXY+SSd2ZSBmb3VuZGVkIHRoYXQgcGdfZHVtcCAo
YW5kIHBnX2R1bXBhbGwpIGluY29ycmVjdGx0eSBleHBvcnRzIHN1YnNlcXVlbnQgZGVmYXVsdCBw
cml2aWxlZ2VzLjwvZGl2PjxkaXY+RXguOjwvZGl2PjxkaXY+Jmd0OyBBTFRFUiBERUZBVUxUIFBS
SVZJTEVHRVMgRk9SIFJPTEUgcG9zdGdyZXMgUkVWT0tFIEFMTCBPTiBGVU5DVElPTlMgRlJPTSBQ
VUJMSUM7PC9kaXY+PGRpdj4mZ3Q7IEFMVEVSIERFRkFVTFQgUFJJVklMRUdFUyBGT1IgUk9MRSBw
b3N0Z3JlcyBJTiBTQ0hFTUEgYmFyIEdSQU5UIEVYRUNVVEUgT04gRlVOQ1RJT05TIFRPIFBVQkxJ
Qzs8L2Rpdj48ZGl2PiZndDsgYnVnPSMgXGRkcDwvZGl2PjxkaXY+Jmd0OyDCoCDCoCDCoCDCoCDC
oCDCoCDCoERlZmF1bHQgYWNjZXNzIHByaXZpbGVnZXM8L2Rpdj48ZGl2PiZndDsgwqAgT3duZXIg
wqAgfCBTY2hlbWEgfCDCoCBUeXBlIMKgIHwgwqBBY2Nlc3MgcHJpdmlsZWdlczwvZGl2PjxkaXY+
Jmd0OyAtLS0tLS0tLS0tKy0tLS0tLS0tKy0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t
PC9kaXY+PGRpdj4mZ3Q7IMKgcG9zdGdyZXMgfCBiYXIgwqAgwqB8IGZ1bmN0aW9uIHwgPVgvcG9z
dGdyZXM8L2Rpdj48ZGl2PiZndDsgwqBwb3N0Z3JlcyB8IMKgIMKgIMKgIMKgfCBmdW5jdGlvbiB8
IHBvc3RncmVzPVgvcG9zdGdyZXM8L2Rpdj48ZGl2PiZndDsgLS0gSSBjYW4gZXhlY3V0ZSBuZXds
eSBjcmVhdGVkIGZ1bmN0aW9ucyBvbiBzY2hlbWUgJ2JhcicgYWZ0ZXIgdGhhdC48L2Rpdj48ZGl2
PsKgPC9kaXY+PGRpdj53aWxsIGJlIGV4cG9ydGVkIGFzOjwvZGl2PjxkaXY+Jmd0OyBBTFRFUiBE
RUZBVUxUIFBSSVZJTEVHRVMgRk9SIFJPTEUgcG9zdGdyZXMgSU4gU0NIRU1BIGJhciBSRVZPS0Ug
QUxMIE9OIEZVTkNUSU9OUyDCoEZST00gcG9zdGdyZXM7PC9kaXY+PGRpdj4mZ3Q7IEFMVEVSIERF
RkFVTFQgUFJJVklMRUdFUyBGT1IgUk9MRSBwb3N0Z3JlcyBSRVZPS0UgQUxMIE9OIEZVTkNUSU9O
UyDCoEZST00gUFVCTElDOzwvZGl2PjxkaXY+Jmd0OyBidWc9IyBcZGRwPC9kaXY+PGRpdj4mZ3Q7
IMKgIMKgIMKgIMKgIMKgIMKgIMKgRGVmYXVsdCBhY2Nlc3MgcHJpdmlsZWdlczwvZGl2PjxkaXY+
Jmd0OyDCoCBPd25lciDCoCB8IFNjaGVtYSB8IMKgIFR5cGUgwqAgfCDCoEFjY2VzcyBwcml2aWxl
Z2VzIMKgPC9kaXY+PGRpdj4mZ3Q7IC0tLS0tLS0tLS0rLS0tLS0tLS0rLS0tLS0tLS0tLSstLS0t
LS0tLS0tLS0tLS0tLS0tLS08L2Rpdj48ZGl2PiZndDsgwqBwb3N0Z3JlcyB8IMKgIMKgIMKgIMKg
fCBmdW5jdGlvbiB8IHBvc3RncmVzPVgvcG9zdGdyZXM8L2Rpdj48ZGl2PiZndDsgLS0gSSBjYW4g
Tk9UIGV4ZWN1dGUgbmV3bHkgY3JlYXRlZCBmdW5jdGlvbnMgb24gc2NoZW1lICdiYXInIGFmdGVy
IHRoYXQuPC9kaXY+PGRpdj7CoDwvZGl2PjxkaXY+QWZ0ZXIgcmVzdG9yaW5nIHRoZSBkdW1wIEkg
Y2Fubm90IGV4ZWN1dGUgbmV3bHkgY3JlYXRlZCBmdW5jdGlvbnMgb24gc2NoZW1lICdiYXInLjwv
ZGl2PjxkaXY+SSd2ZSBhdHRhY2hlZCB0aGUgc2hlbGwtc2NyaXB0IHRoYXQgY3JlYXRlIHRoZSBl
bnZpcm9ubWVudC48L2Rpdj48ZGl2PsKgPC9kaXY+PGRpdj5JIGNyZWF0ZSBhIGZ1bmN0aW9uIGFm
dGVyIGR1bXAgb3IgcmVzdG9yZSBwcm9jZWR1cmVzIChleC4gYmFja3VwIHB1cnBvc2VzKTo8L2Rp
dj48ZGl2PjxkaXY+Jmd0OyBDUkVBVEUgRlVOQ1RJT04gYmFyLm5ldygpIFJFVFVSTlMgYm9vbDwv
ZGl2PjxkaXY+Jmd0OyDCoCDCoCBJTU1VVEFCTEU8L2Rpdj48ZGl2PiZndDsgwqAgwqAgTEFOR1VB
R0Ugc3FsPC9kaXY+PGRpdj4mZ3Q7IEFTICdTRUxFQ1QgVFJVRTsnOzwvZGl2PjxkaXY+VGhlIGZ1
bmN0aW9uIGJhci5uZXcoKSBjYW5ub3QgYmUgZXhlY3V0ZWQgYnkgJ2J1ZycgdXNlciBpZiBjcmVh
dGVkIGFmdGVyIHRoZSByZXN0b3JlIHByb2NlZHVyZS48L2Rpdj48ZGl2PkkndmUgZ290IGFuIGVy
cm9yOiBFUlJPUjogwqBwZXJtaXNzaW9uIGRlbmllZCBmb3IgZnVuY3Rpb24gbmV3LjwvZGl2Pjxk
aXY+wqA8L2Rpdj48L2Rpdj48ZGl2PldCUiw8L2Rpdj48ZGl2PkJvcmlzPC9kaXY+PC9kaXY+
------==--bound.1064580.iva5-4e96f110c519.qloud-c.yandex.net
Content-Disposition: attachment;
filename="sql-def_priv_bug.sh"
Content-Transfer-Encoding: base64
Content-Type: text/x-shellscript;
name="sql-def_priv_bug.sh"
IyEvYmluL3NoCgpQU1FMPSJwc3FsIC12IE9OX0VSUk9SX1NUT1A9MSIKCmV4cG9ydCBQR1VTRVI9
InBvc3RncmVzIgpleHBvcnQgUEdIT1NUPSIxMjcuMC4wLjEiCmV4cG9ydCBQR1BPUlQ9IjU0MzIi
CmV4cG9ydCBQR1NTTE1PREU9ImRpc2FibGUiCgpleHBvcnQgUEdEQVRBQkFTRT0idGVtcGxhdGUx
IgpleHBvcnQgUEdVU0VSPSJwb3N0Z3JlcyIKCiR7UFNRTH0gPDwgRSpPKkYgfHwgZXhpdCAxClNF
TEVDVCBwZ190ZXJtaW5hdGVfYmFja2VuZChwaWQpCkZST00gcGdfc3RhdF9hY3Rpdml0eQpXSEVS
RSBkYXRuYW1lID0gJ2J1ZycKICBBTkQgcGlkIDw+IHBnX2JhY2tlbmRfcGlkKCk7CgpEUk9QIERB
VEFCQVNFIElGIEVYSVNUUyAiYnVnIjsKCkRST1AgUk9MRSBJRiBFWElTVFMgImJ1ZyI7CkNSRUFU
RSBST0xFICJidWciIE5PSU5IRVJJVCBMT0dJTiBCWVBBU1NSTFMgUEFTU1dPUkQgJzEyMzQ1Nic7
CgpDUkVBVEUgREFUQUJBU0UgImJ1ZyI7CkUqTypGCgpleHBvcnQgUEdEQVRBQkFTRT0iYnVnIgpl
eHBvcnQgUEdVU0VSPSJwb3N0Z3JlcyIKCiR7UFNRTH0gLXEgPDwgRSpPKkYgfHwgZXhpdCAxCkFM
VEVSIERFRkFVTFQgUFJJVklMRUdFUyBSRVZPS0UgQUxMIE9OIEZVTkNUSU9OUyBGUk9NIFBVQkxJ
QzsKCkNSRUFURSBTQ0hFTUEgZm9vOwpHUkFOVCBVU0FHRSBPTiBTQ0hFTUEgZm9vIFRPICJidWci
OwpDUkVBVEUgRlVOQ1RJT04gZm9vLmZvbygpIFJFVFVSTlMgYm9vbAogICAgSU1NVVRBQkxFCiAg
ICBMQU5HVUFHRSBzcWwKQVMKXCRfXCQKU0VMRUNUIFRSVUU7ClwkX1wkOwoKQ1JFQVRFIFNDSEVN
QSBiYXI7CkdSQU5UIFVTQUdFIE9OIFNDSEVNQSBiYXIgVE8gImJ1ZyI7CkFMVEVSIERFRkFVTFQg
UFJJVklMRUdFUyBJTiBTQ0hFTUEgYmFyIEdSQU5UIEVYRUNVVEUgT04gRlVOQ1RJT05TIFRPIFBV
QkxJQzsKQ1JFQVRFIEZVTkNUSU9OIGJhci5iYXIoKSBSRVRVUk5TIGJvb2wKICAgIElNTVVUQUJM
RQogICAgTEFOR1VBR0Ugc3FsCkFTClwkX1wkClNFTEVDVCBGQUxTRTsKXCRfXCQ7CkUqTypG
------==--bound.1064580.iva5-4e96f110c519.qloud-c.yandex.net--
Attachments:
sql-def_priv_bug.sh (text/x-shellscript, 1023B) download
#!/bin/sh
PSQL="psql -v ON_ERROR_STOP=1"
export PGUSER="postgres"
export PGHOST="127.0.0.1"
export PGPORT="5432"
export PGSSLMODE="disable"
export PGDATABASE="template1"
export PGUSER="postgres"
${PSQL} << E*O*F || exit 1
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE datname = 'bug'
AND pid <> pg_backend_pid();
DROP DATABASE IF EXISTS "bug";
DROP ROLE IF EXISTS "bug";
CREATE ROLE "bug" NOINHERIT LOGIN BYPASSRLS PASSWORD '123456';
CREATE DATABASE "bug";
E*O*F
export PGDATABASE="bug"
export PGUSER="postgres"
${PSQL} -q << E*O*F || exit 1
ALTER DEFAULT PRIVILEGES REVOKE ALL ON FUNCTIONS FROM PUBLIC;
CREATE SCHEMA foo;
GRANT USAGE ON SCHEMA foo TO "bug";
CREATE FUNCTION foo.foo() RETURNS bool
IMMUTABLE
LANGUAGE sql
AS
\$_\$
SELECT TRUE;
\$_\$;
CREATE SCHEMA bar;
GRANT USAGE ON SCHEMA bar TO "bug";
ALTER DEFAULT PRIVILEGES IN SCHEMA bar GRANT EXECUTE ON FUNCTIONS TO PUBLIC;
CREATE FUNCTION bar.bar() RETURNS bool
IMMUTABLE
LANGUAGE sql
AS
\$_\$
SELECT FALSE;
\$_\$;
E*O*F
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-03-31 03:02 Neil Chen <carpenter.nail.cz@gmail.com>
0 siblings, 2 replies; 26+ messages in thread
From: Neil Chen @ 2021-03-31 03:02 UTC (permalink / raw)
To: drtr0jan@yandex.ru; +Cc: pgsql-bugs@lists.postgresql.org
Greetings,
I did some research on this bug and found that the reason for the problem
is that the pg_dump misjudged the non-global default access privileges when
exporting. The details are as follows:
> The default for a global entry is the hard-wired default ACL for the
> particular object type. The default for non-global entries is an empty
> ACL. This must be so because global entries replace the hard-wired
> defaults, while others are added on.
>
We can find this description in code
comments(src/backend/catalog/aclchk.c:1162). For example, if we log as user
postgres, for global entire our default ACL is
"{=X/postgres,postgres=X/postgres}", for non-global entire it's "NULL".
Now let's look at a part of the SQL statement used when pg_dump exports the
default ACL(it can be found in src/bin/pg_dump/dumputils.c:762):
> (SELECT pg_catalog.array_agg(acl ORDER BY row_n) FROM
> (SELECT acl, row_n FROM
> pg_catalog.unnest(coalesce(defaclacl,pg_catalog.acldefault(CASE WHEN
> defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::"char",defaclrole)))
> WITH ORDINALITY AS perm(acl,row_n)
> WHERE NOT EXISTS (
> SELECT 1 FROM
> pg_catalog.unnest(coalesce(pip.initprivs,pg_catalog.acldefault(CASE WHEN
> defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::"char",defaclrole)))
> AS init(init_acl) WHERE acl = init_acl)) as foo)
It can be seen that when comparing the changes of default ACL, it does not
distinguish between global and non-global default ACL. It uses
{=X/postgres,postgres=X/postgres} as the non-global default ACL by mistake,
resulting in the export error.
Combined with the above research, I gave this patch to fix the bug. Hackers
can help to see if this modification is correct. I'm studying how to write
test scripts for it...
Thanks.
--
There is no royal road to learning.
HighGo Software Co.
Attachments:
0001-fix-bug-on-dump-default-ACL.patch (application/octet-stream, 975B) download
From d85edeb046557aae8a592d20ea1749016dcba454 Mon Sep 17 00:00:00 2001
From: Neil Chen <chenze@highgo.com>
Date: Wed, 31 Mar 2021 11:00:55 +0800
Subject: [PATCH] fix bug on dump default ACL
---
src/bin/pg_dump/pg_dump.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index da6cc054b0..05686c7a94 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -9793,7 +9793,9 @@ getDefaultACLs(Archive *fout, int *numDefaultACLs)
buildACLQueries(acl_subquery, racl_subquery, initacl_subquery,
initracl_subquery, "defaclacl", "defaclrole",
- "CASE WHEN defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::\"char\"",
+ "CASE WHEN defaclnamespace = 0 THEN "
+ "CASE WHEN defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::\"char\" "
+ "ELSE NULL END",
dopt->binary_upgrade);
appendPQExpBuffer(query, "SELECT d.oid, d.tableoid, "
--
2.25.1
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-03-31 03:30 Neil Chen <carpenter.nail.cz@gmail.com>
parent: Neil Chen <carpenter.nail.cz@gmail.com>
1 sibling, 1 reply; 26+ messages in thread
From: Neil Chen @ 2021-03-31 03:30 UTC (permalink / raw)
To: drtr0jan@yandex.ru; +Cc: pgsql-bugs@lists.postgresql.org
Sorry I used the wrong way to send the email. The email about the bug is
here:
https://www.postgresql.org/message-id/111621616618184%40mail.yandex.ru
On Wed, Mar 31, 2021 at 11:02 AM Neil Chen <carpenter.nail.cz@gmail.com>
wrote:
> Greetings,
>
> I did some research on this bug and found that the reason for the problem
> is that the pg_dump misjudged the non-global default access privileges when
> exporting. The details are as follows:
>
>> The default for a global entry is the hard-wired default ACL for the
>> particular object type. The default for non-global entries is an empty
>> ACL. This must be so because global entries replace the hard-wired
>> defaults, while others are added on.
>>
> We can find this description in code
> comments(src/backend/catalog/aclchk.c:1162). For example, if we log as user
> postgres, for global entire our default ACL is
> "{=X/postgres,postgres=X/postgres}", for non-global entire it's "NULL".
>
> Now let's look at a part of the SQL statement used when pg_dump exports
> the default ACL(it can be found in src/bin/pg_dump/dumputils.c:762):
>
>> (SELECT pg_catalog.array_agg(acl ORDER BY row_n) FROM
>> (SELECT acl, row_n FROM
>> pg_catalog.unnest(coalesce(defaclacl,pg_catalog.acldefault(CASE WHEN
>> defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::"char",defaclrole)))
>> WITH ORDINALITY AS perm(acl,row_n)
>> WHERE NOT EXISTS (
>> SELECT 1 FROM
>> pg_catalog.unnest(coalesce(pip.initprivs,pg_catalog.acldefault(CASE WHEN
>> defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::"char",defaclrole)))
>> AS init(init_acl) WHERE acl = init_acl)) as foo)
>
> It can be seen that when comparing the changes of default ACL, it does not
> distinguish between global and non-global default ACL. It uses
> {=X/postgres,postgres=X/postgres} as the non-global default ACL by mistake,
> resulting in the export error.
>
> Combined with the above research, I gave this patch to fix the
> bug. Hackers can help to see if this modification is correct. I'm studying
> how to write test scripts for it...
>
> Thanks.
>
> --
> There is no royal road to learning.
> HighGo Software Co.
>
--
There is no royal road to learning.
HighGo Software Co.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-04-02 14:09 Boris P. Korzun <drtr0jan@yandex.ru>
parent: Neil Chen <carpenter.nail.cz@gmail.com>
0 siblings, 0 replies; 26+ messages in thread
From: Boris P. Korzun @ 2021-04-02 14:09 UTC (permalink / raw)
To: Neil Chen <carpenter.nail.cz@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org
Hi Neil,
> Combined with the above research, I gave this patch to fix the
> bug. Hackers can help to see if this modification is correct. I'm
> studying how to write test scripts for it...
it works. Thx.
WBR,
Boris
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-09-21 05:04 Boris P. Korzun <drtr0jan@yandex.ru>
parent: Neil Chen <carpenter.nail.cz@gmail.com>
1 sibling, 1 reply; 26+ messages in thread
From: Boris P. Korzun @ 2021-09-21 05:04 UTC (permalink / raw)
To: Neil Chen <carpenter.nail.cz@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
<div>Hi Neil,</div><div> </div><div>what about the commit to the upstream?</div><div> </div><div>31.03.2021, 06:02, "Neil Chen" <carpenter.nail.cz@gmail.com>:</div><blockquote><div>Greetings,<div> </div><div>I did some research on this bug and found that the reason for the problem is that the pg_dump misjudged the non-global default access privileges when exporting. The details are as follows:</div><blockquote>The default for a global entry is the hard-wired default ACL for the<br />particular object type. The default for non-global entries is an empty<br />ACL. This must be so because global entries replace the hard-wired<br />defaults, while others are added on.</blockquote><div>We can find this description in code comments(src/backend/catalog/aclchk.c:1162). For example, if we log as user postgres, for global entire our default ACL is "{=X/postgres,postgres=X/postgres}", for non-global entire it's "NULL".</div><div> </div><div>Now let's look at a part of the SQL statement used when pg_dump exports the default ACL(it can be found in src/bin/pg_dump/dumputils.c:762):</div><blockquote>(SELECT pg_catalog.array_agg(acl ORDER BY row_n) FROM<br />(SELECT acl, row_n FROM<br />pg_catalog.unnest(coalesce(defaclacl,pg_catalog.acldefault(CASE WHEN defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::"char",defaclrole)))<br />WITH ORDINALITY AS perm(acl,row_n)<br />WHERE NOT EXISTS (<br />SELECT 1 FROM<br />pg_catalog.unnest(coalesce(pip.initprivs,pg_catalog.acldefault(CASE WHEN defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::"char",defaclrole)))<br />AS init(init_acl) WHERE acl = init_acl)) as foo) </blockquote><div>It can be seen that when comparing the changes of default ACL, it does not distinguish between global and non-global default ACL. It uses {=X/postgres,postgres=X/postgres} as the non-global default ACL by mistake, resulting in the export error.</div><div> </div><div>Combined with the above research, I gave this patch to fix the bug. Hackers can help to see if this modification is correct. I'm studying how to write test scripts for it...</div><div> </div><div>Thanks.</div><div> </div>--<div><div>There is no royal road to learning.<div>HighGo Software Co.</div></div></div></div></blockquote><div>---</div><div>WBR</div><div>Boris</div>
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-09-22 01:30 Neil Chen <carpenter.nail.cz@gmail.com>
parent: Boris P. Korzun <drtr0jan@yandex.ru>
0 siblings, 2 replies; 26+ messages in thread
From: Neil Chen @ 2021-09-22 01:30 UTC (permalink / raw)
To: Boris P. Korzun <drtr0jan@yandex.ru>; +Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Hi Boris,
Actually, because I am a PG beginner, I am not familiar with the rules of
the community. What extra work do I need to do to submit to the upstream?
This bug discussion doesn't seem to see the concern of others.
On Tue, Sep 21, 2021 at 1:05 PM Boris P. Korzun <drtr0jan@yandex.ru> wrote:
> Hi Neil,
>
> what about the commit to the upstream?
>
> ---
> WBR
> Boris
>
--
There is no royal road to learning.
HighGo Software Co.
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-01 14:13 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Neil Chen <carpenter.nail.cz@gmail.com>
1 sibling, 2 replies; 26+ messages in thread
From: Masahiko Sawada @ 2021-10-01 14:13 UTC (permalink / raw)
To: Neil Chen <carpenter.nail.cz@gmail.com>; +Cc: Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Wed, Sep 22, 2021 at 10:31 AM Neil Chen <carpenter.nail.cz@gmail.com> wrote:
>
> Hi Boris,
>
> Actually, because I am a PG beginner, I am not familiar with the rules of the community. What extra work do I need to do to submit to the upstream? This bug discussion doesn't seem to see the concern of others.
As far as I checked this bug still exists in all supported branches
(from 10 to 14, and HEAD). I'd recommend adding this patch to the next
commit fest so as not to forget, if not yet.
I agree with your analysis on this bug. For non-default
(defaclnamespace != 0) entries, their acl should be compared to NULL.
The fix also looks good to me. But I think it'd be better to add tests for this.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-13 08:22 Boris Korzun <drtr0jan@yandex.ru>
parent: Neil Chen <carpenter.nail.cz@gmail.com>
1 sibling, 0 replies; 26+ messages in thread
From: Boris Korzun @ 2021-10-13 08:22 UTC (permalink / raw)
To: Neil Chen <carpenter.nail.cz@gmail.com>; +Cc: pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Hi Neil,
you should send the patch via e-mail to the pgsql-hackers (
http://www.postgresql.org/list/pgsql-hackers/ ) mailing list for adding
to the next commit fest as Masahiko Sawada said.
I can help you if you have any questions.
On 22/09/2021 04:30, Neil Chen wrote:
> Hi Boris,
>
> Actually, because I am a PG beginner, I am not familiar with the rules
> of the community. What extra work do I need to do to submit to the
> upstream? This bug discussion doesn't seem to see the concern of others.
>
> On Tue, Sep 21, 2021 at 1:05 PM Boris P. Korzun <drtr0jan@yandex.ru>
> wrote:
>
> Hi Neil,
> what about the commit to the upstream?
> ---
> WBR
> Boris
>
>
>
> --
> There is no royal road to learning.
> HighGo Software Co.
---
WBR
Boris
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-14 00:36 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
1 sibling, 1 reply; 26+ messages in thread
From: Masahiko Sawada @ 2021-10-14 00:36 UTC (permalink / raw)
To: Neil Chen <carpenter.nail.cz@gmail.com>; +Cc: Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>; PostgreSQL-development <pgsql-hackers@postgresql.org>
Hi,
On Fri, Oct 1, 2021 at 11:13 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Sep 22, 2021 at 10:31 AM Neil Chen <carpenter.nail.cz@gmail.com> wrote:
> >
> > Hi Boris,
> >
> > Actually, because I am a PG beginner, I am not familiar with the rules of the community. What extra work do I need to do to submit to the upstream? This bug discussion doesn't seem to see the concern of others.
>
> As far as I checked this bug still exists in all supported branches
> (from 10 to 14, and HEAD). I'd recommend adding this patch to the next
> commit fest so as not to forget, if not yet.
>
> I agree with your analysis on this bug. For non-default
> (defaclnamespace != 0) entries, their acl should be compared to NULL.
>
> The fix also looks good to me. But I think it'd be better to add tests for this.
Since the patch conflicts with the current HEAD, I've rebased and
slightly updated the patch, adding the regression tests.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
Attachments:
fix-bug-on-dump-default-ACL_v2.patch (application/octet-stream, 2.0K) download
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index a485fb2d07..31d5c03b7b 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -9860,10 +9860,17 @@ getDefaultACLs(Archive *fout, int *numDefaultACLs)
PQExpBuffer initacl_subquery = createPQExpBuffer();
PQExpBuffer initracl_subquery = createPQExpBuffer();
+ /*
+ * The default for a global entry is the hard-wired default ACL
+ * whereas the default for non-global entries is an empty ACL.
+ */
buildACLQueries(acl_subquery, racl_subquery, initacl_subquery,
initracl_subquery, "defaclacl", "defaclrole",
"pip.initprivs",
- "CASE WHEN defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::\"char\"",
+ "CASE WHEN defaclnamespace = 0 THEN "
+ " CASE WHEN defaclobjtype = 'S' THEN 's' "
+ " ELSE defaclobjtype END::\"char\" "
+ "ELSE NULL END",
dopt->binary_upgrade);
appendPQExpBuffer(query, "SELECT d.oid, d.tableoid, "
diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_dump.pl
index c61d95e817..31cf14a592 100644
--- a/src/bin/pg_dump/t/002_pg_dump.pl
+++ b/src/bin/pg_dump/t/002_pg_dump.pl
@@ -443,6 +443,24 @@ my %tests = (
},
},
+ 'ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role GRANT EXECUTE ON FUNCTIONS' => {
+ create_order => 15,
+ create_sql => 'ALTER DEFAULT PRIVILEGES
+ FOR ROLE regress_dump_test_role IN SCHEMA dump_test
+ GRANT EXECUTE ON FUNCTIONS TO regress_dump_test_role;',
+ regexp => qr/^
+ \QALTER DEFAULT PRIVILEGES \E
+ \QFOR ROLE regress_dump_test_role IN SCHEMA dump_test \E
+ \QGRANT ALL ON FUNCTIONS TO regress_dump_test_role;\E
+ /xm,
+ like =>
+ { %full_runs, %dump_test_schema_runs, section_post_data => 1, },
+ unlike => {
+ exclude_dump_test_schema => 1,
+ no_privs => 1,
+ },
+ },
+
'ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role REVOKE' => {
create_order => 55,
create_sql => 'ALTER DEFAULT PRIVILEGES
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-14 00:59 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
1 sibling, 0 replies; 26+ messages in thread
From: Masahiko Sawada @ 2021-10-14 00:59 UTC (permalink / raw)
To: Neil Chen <carpenter.nail.cz@gmail.com>; +Cc: Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Fri, Oct 1, 2021 at 11:13 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Sep 22, 2021 at 10:31 AM Neil Chen <carpenter.nail.cz@gmail.com> wrote:
> >
> > Hi Boris,
> >
> > Actually, because I am a PG beginner, I am not familiar with the rules of the community. What extra work do I need to do to submit to the upstream? This bug discussion doesn't seem to see the concern of others.
>
> As far as I checked this bug still exists in all supported branches
> (from 10 to 14, and HEAD). I'd recommend adding this patch to the next
> commit fest so as not to forget, if not yet.
>
> I agree with your analysis on this bug. For non-default
> (defaclnamespace != 0) entries, their acl should be compared to NULL.
>
> The fix also looks good to me. But I think it'd be better to add tests for this.
>
Since the patch conflicts with the current HEAD, I've rebased and
slightly updated the patch, adding the regression tests.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
Attachments:
fix-bug-on-dump-default-ACL_v2.patch (application/octet-stream, 2.0K) download
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index a485fb2d07..31d5c03b7b 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -9860,10 +9860,17 @@ getDefaultACLs(Archive *fout, int *numDefaultACLs)
PQExpBuffer initacl_subquery = createPQExpBuffer();
PQExpBuffer initracl_subquery = createPQExpBuffer();
+ /*
+ * The default for a global entry is the hard-wired default ACL
+ * whereas the default for non-global entries is an empty ACL.
+ */
buildACLQueries(acl_subquery, racl_subquery, initacl_subquery,
initracl_subquery, "defaclacl", "defaclrole",
"pip.initprivs",
- "CASE WHEN defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::\"char\"",
+ "CASE WHEN defaclnamespace = 0 THEN "
+ " CASE WHEN defaclobjtype = 'S' THEN 's' "
+ " ELSE defaclobjtype END::\"char\" "
+ "ELSE NULL END",
dopt->binary_upgrade);
appendPQExpBuffer(query, "SELECT d.oid, d.tableoid, "
diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_dump.pl
index c61d95e817..31cf14a592 100644
--- a/src/bin/pg_dump/t/002_pg_dump.pl
+++ b/src/bin/pg_dump/t/002_pg_dump.pl
@@ -443,6 +443,24 @@ my %tests = (
},
},
+ 'ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role GRANT EXECUTE ON FUNCTIONS' => {
+ create_order => 15,
+ create_sql => 'ALTER DEFAULT PRIVILEGES
+ FOR ROLE regress_dump_test_role IN SCHEMA dump_test
+ GRANT EXECUTE ON FUNCTIONS TO regress_dump_test_role;',
+ regexp => qr/^
+ \QALTER DEFAULT PRIVILEGES \E
+ \QFOR ROLE regress_dump_test_role IN SCHEMA dump_test \E
+ \QGRANT ALL ON FUNCTIONS TO regress_dump_test_role;\E
+ /xm,
+ like =>
+ { %full_runs, %dump_test_schema_runs, section_post_data => 1, },
+ unlike => {
+ exclude_dump_test_schema => 1,
+ no_privs => 1,
+ },
+ },
+
'ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role REVOKE' => {
create_order => 55,
create_sql => 'ALTER DEFAULT PRIVILEGES
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-14 02:55 Tom Lane <tgl@sss.pgh.pa.us>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
0 siblings, 1 reply; 26+ messages in thread
From: Tom Lane @ 2021-10-14 02:55 UTC (permalink / raw)
To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>; PostgreSQL-development <pgsql-hackers@postgresql.org>
Masahiko Sawada <sawada.mshk@gmail.com> writes:
>> I agree with your analysis on this bug. For non-default
>> (defaclnamespace != 0) entries, their acl should be compared to NULL.
>>
>> The fix also looks good to me. But I think it'd be better to add tests for this.
> Since the patch conflicts with the current HEAD, I've rebased and
> slightly updated the patch, adding the regression tests.
Hmmm ... if we're adding a comment about the defaclnamespace check,
seems like it would also be a nice idea to explain the S-to-s
transformation, because the reason for that is surely not apparent.
regards, tom lane
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-14 05:22 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 26+ messages in thread
From: Masahiko Sawada @ 2021-10-14 05:22 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Thu, Oct 14, 2021 at 11:55 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Masahiko Sawada <sawada.mshk@gmail.com> writes:
> >> I agree with your analysis on this bug. For non-default
> >> (defaclnamespace != 0) entries, their acl should be compared to NULL.
> >>
> >> The fix also looks good to me. But I think it'd be better to add tests for this.
>
> > Since the patch conflicts with the current HEAD, I've rebased and
> > slightly updated the patch, adding the regression tests.
>
> Hmmm ... if we're adding a comment about the defaclnamespace check,
> seems like it would also be a nice idea to explain the S-to-s
> transformation, because the reason for that is surely not apparent.
>
Agreed. Please find an attached new patch.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
Attachments:
fix-bug-on-dump-default-ACL_v3.patch (application/octet-stream, 2.2K) download
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index a485fb2d07..62f78eae3c 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -9860,10 +9860,21 @@ getDefaultACLs(Archive *fout, int *numDefaultACLs)
PQExpBuffer initacl_subquery = createPQExpBuffer();
PQExpBuffer initracl_subquery = createPQExpBuffer();
+ /*
+ * The default for a global entry is the hard-wired default ACL
+ * for the particular object type, whereas the default for
+ * non-global entries is an empty ACL. Also, we need to
+ * transform the object type char 'S' (DEFACLOBJ_SEQUENCE) to
+ * 's' since acldefault() SQL-callable function handles 's'
+ * as a sequence.
+ */
buildACLQueries(acl_subquery, racl_subquery, initacl_subquery,
initracl_subquery, "defaclacl", "defaclrole",
"pip.initprivs",
- "CASE WHEN defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::\"char\"",
+ "CASE WHEN defaclnamespace = 0 THEN "
+ " CASE WHEN defaclobjtype = 'S' THEN 's' "
+ " ELSE defaclobjtype END::\"char\" "
+ "ELSE NULL END",
dopt->binary_upgrade);
appendPQExpBuffer(query, "SELECT d.oid, d.tableoid, "
diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_dump.pl
index c61d95e817..31cf14a592 100644
--- a/src/bin/pg_dump/t/002_pg_dump.pl
+++ b/src/bin/pg_dump/t/002_pg_dump.pl
@@ -443,6 +443,24 @@ my %tests = (
},
},
+ 'ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role GRANT EXECUTE ON FUNCTIONS' => {
+ create_order => 15,
+ create_sql => 'ALTER DEFAULT PRIVILEGES
+ FOR ROLE regress_dump_test_role IN SCHEMA dump_test
+ GRANT EXECUTE ON FUNCTIONS TO regress_dump_test_role;',
+ regexp => qr/^
+ \QALTER DEFAULT PRIVILEGES \E
+ \QFOR ROLE regress_dump_test_role IN SCHEMA dump_test \E
+ \QGRANT ALL ON FUNCTIONS TO regress_dump_test_role;\E
+ /xm,
+ like =>
+ { %full_runs, %dump_test_schema_runs, section_post_data => 1, },
+ unlike => {
+ exclude_dump_test_schema => 1,
+ no_privs => 1,
+ },
+ },
+
'ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role REVOKE' => {
create_order => 55,
create_sql => 'ALTER DEFAULT PRIVILEGES
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-14 07:53 Michael Paquier <michael@paquier.xyz>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
0 siblings, 3 replies; 26+ messages in thread
From: Michael Paquier @ 2021-10-14 07:53 UTC (permalink / raw)
To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Thu, Oct 14, 2021 at 02:22:21PM +0900, Masahiko Sawada wrote:
> Agreed. Please find an attached new patch.
I have not dived into the details of the patch yet, but I can see the
following diffs in some of the dumps dropped by the new test added
between HEAD and the patch:
1) For DEFAULT PRIVILEGES FOR FUNCTIONS:
-ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test REVOKE ALL ON FUNCTIONS FROM PUBLIC;
+ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test GRANT ALL ON FUNCTIONS TO regress_dump_test_role;
2) For DEFAULT PRIVILEGES FOR TABLES:
-ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test REVOKE ALL ON TABLES FROM regress_dump_test_role;
ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test GRANT SELECT ON TABLES TO regress_dump_test_role;
So the patch removes a REVOKE ALL ON TABLES on
regress_dump_test_role after the addition of only the GRANT EXECUTE ON
FUNCTIONS. That seems off. Am I missing something?
--
Michael
Attachments:
signature.asc (application/pgp-signature, 832B) download
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-14 16:02 Bossart, Nathan <bossartn@amazon.com>
parent: Michael Paquier <michael@paquier.xyz>
2 siblings, 0 replies; 26+ messages in thread
From: Bossart, Nathan @ 2021-10-14 16:02 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 10/14/21, 12:55 AM, "Michael Paquier" <michael@paquier.xyz> wrote:
> So the patch removes a REVOKE ALL ON TABLES on
> regress_dump_test_role after the addition of only the GRANT EXECUTE ON
> FUNCTIONS. That seems off. Am I missing something?
This issue is also tracked here:
https://commitfest.postgresql.org/35/3288/
I had attempted to fix this by replacing acldefault() with NULL when
defaclnamespace was 0. From a quick glance, the patch in this thread
seems to be adjusting obj_kind based on whether defaclnamespace is 0.
I think this has the same effect because acldefault() is STRICT.
Nathan
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-14 16:13 Bossart, Nathan <bossartn@amazon.com>
parent: Michael Paquier <michael@paquier.xyz>
2 siblings, 0 replies; 26+ messages in thread
From: Bossart, Nathan @ 2021-10-14 16:13 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 10/14/21, 12:55 AM, "Michael Paquier" <michael@paquier.xyz> wrote:
> 1) For DEFAULT PRIVILEGES FOR FUNCTIONS:
> -ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
> dump_test REVOKE ALL ON FUNCTIONS FROM PUBLIC;
> +ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
> dump_test GRANT ALL ON FUNCTIONS TO regress_dump_test_role;
This one looks correct to me.
> 2) For DEFAULT PRIVILEGES FOR TABLES:
> -ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
> dump_test REVOKE ALL ON TABLES FROM regress_dump_test_role;
> ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
> dump_test GRANT SELECT ON TABLES TO regress_dump_test_role;
>
> So the patch removes a REVOKE ALL ON TABLES on
> regress_dump_test_role after the addition of only the GRANT EXECUTE ON
> FUNCTIONS. That seems off. Am I missing something?
I might be missing something as well, but this one looks correct to
me, too. I suspect that REVOKE statement was generated by comparing
against the wrong default ACL and that it actually has no effect.
Nathan
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-15 00:05 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Michael Paquier <michael@paquier.xyz>
2 siblings, 1 reply; 26+ messages in thread
From: Masahiko Sawada @ 2021-10-15 00:05 UTC (permalink / raw)
To: Michael Paquier <michael@paquier.xyz>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Thu, Oct 14, 2021 at 4:53 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Thu, Oct 14, 2021 at 02:22:21PM +0900, Masahiko Sawada wrote:
> > Agreed. Please find an attached new patch.
>
> I have not dived into the details of the patch yet, but I can see the
> following diffs in some of the dumps dropped by the new test added
> between HEAD and the patch:
I've checked where these differences come from:
> 1) For DEFAULT PRIVILEGES FOR FUNCTIONS:
> -ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
> dump_test REVOKE ALL ON FUNCTIONS FROM PUBLIC;
> +ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
> dump_test GRANT ALL ON FUNCTIONS TO regress_dump_test_role;
The test query and the default privileges I got are:
ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test GRANT EXECUTE ON FUNCTIONS TO regress_dump_test_role;
Default access privileges
Owner | Schema | Type | Access
privileges
------------------------+-----------+----------+-------------------------------------------------
regress_dump_test_role | dump_test | function |
regress_dump_test_role=X/regress_dump_test_role
(1 row)
The query dumped by the current pg_dump (i.g., HEAD, w/o patch) is:
ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test REVOKE ALL ON FUNCTIONS FROM PUBLIC;
The query dumped by pg_dump with the patch is:
ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test GRANT ALL ON FUNCTIONS TO regress_dump_test_role;
The query dumped by the current pg_dump is wrong and the patch fixes
it. This difference looks good to me.
> 2) For DEFAULT PRIVILEGES FOR TABLES:
> -ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
> dump_test REVOKE ALL ON TABLES FROM regress_dump_test_role;
> ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
> dump_test GRANT SELECT ON TABLES TO regress_dump_test_role;
The test query and the default privileges I got are:
ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test GRANT SELECT ON TABLES TO regress_dump_test_role;
Default access privileges
Owner | Schema | Type | Access privileges
------------------------+-----------+-------+-------------------------------------------------
regress_dump_test_role | dump_test | table |
regress_dump_test_role=r/regress_dump_test_role
(1 row)
The query dumped by the current pg_dump (i.g., HEAD, w/o patch) is:
ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test REVOKE ALL ON TABLES FROM regress_dump_test_role;
ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test GRANT SELECT ON TABLES TO regress_dump_test_role;
The query dumped by pg_dump with the patch is:
ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role IN SCHEMA
dump_test GRANT SELECT ON TABLES TO regress_dump_test_role;
The current pg_dump produced a REVOKE ALL ON TABLES FROM
regress_dump_test_role but it seems unnecessary. The patch removes it
so looks good to me too.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-18 23:46 Bossart, Nathan <bossartn@amazon.com>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
0 siblings, 1 reply; 26+ messages in thread
From: Bossart, Nathan @ 2021-10-18 23:46 UTC (permalink / raw)
To: Masahiko Sawada <sawada.mshk@gmail.com>; Michael Paquier <michael@paquier.xyz>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 10/14/21, 5:06 PM, "Masahiko Sawada" <sawada.mshk@gmail.com> wrote:
> The current pg_dump produced a REVOKE ALL ON TABLES FROM
> regress_dump_test_role but it seems unnecessary. The patch removes it
> so looks good to me too.
+1
If we are going to proceed with the patch in this thread, I think we
should also mention in the comment that we are depending on
acldefault() being STRICT. This patch is quite a bit smaller than
what I had proposed, but AFAICT it produces the same result.
Nathan
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-19 02:04 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Bossart, Nathan <bossartn@amazon.com>
0 siblings, 1 reply; 26+ messages in thread
From: Masahiko Sawada @ 2021-10-19 02:04 UTC (permalink / raw)
To: Bossart, Nathan <bossartn@amazon.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Tom Lane <tgl@sss.pgh.pa.us>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Tue, Oct 19, 2021 at 8:47 AM Bossart, Nathan <bossartn@amazon.com> wrote:
>
> On 10/14/21, 5:06 PM, "Masahiko Sawada" <sawada.mshk@gmail.com> wrote:
> > The current pg_dump produced a REVOKE ALL ON TABLES FROM
> > regress_dump_test_role but it seems unnecessary. The patch removes it
> > so looks good to me too.
>
> +1
>
I've looked at the patch proposed you proposed. If we can depend on
acldefault() being STRICT (which is legitimate to me), I think we
don't need to build an expression depending on the caller (i.g.,
is_default_acl). If acldefault() were to become not STRICT, we could
detect it by regression tests. What do you think?
> If we are going to proceed with the patch in this thread, I think we
> should also mention in the comment that we are depending on
> acldefault() being STRICT.
I've updated the patch.
> This patch is quite a bit smaller than
> what I had proposed, but AFAICT it produces the same result.
Yes. I've also confirmed both produce the same result.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
Attachments:
fix-bug-on-dump-default-ACL_v4.patch (application/octet-stream, 2.3K) download
diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c
index 6ec524f8e6..1280b2f4db 100644
--- a/src/bin/pg_dump/pg_dump.c
+++ b/src/bin/pg_dump/pg_dump.c
@@ -9861,10 +9861,22 @@ getDefaultACLs(Archive *fout, int *numDefaultACLs)
PQExpBuffer initacl_subquery = createPQExpBuffer();
PQExpBuffer initracl_subquery = createPQExpBuffer();
+ /*
+ * Since the default for a global entry is the hard-wired default
+ * ACL for the particular object type, we pass defaclobjtype except
+ * for the case of 'S' (DEFACLOBJ_SEQUENCE) where we need to
+ * transform it to 's' since acldefault() SQL-callable function
+ * handles 's' as a sequence. On the other hand, since the default
+ * for non-global entries is an empty ACL we pass NULL. This works
+ * because acldefault() is STRICT.
+ */
buildACLQueries(acl_subquery, racl_subquery, initacl_subquery,
initracl_subquery, "defaclacl", "defaclrole",
"pip.initprivs",
- "CASE WHEN defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::\"char\"",
+ "CASE WHEN defaclnamespace = 0 THEN "
+ " CASE WHEN defaclobjtype = 'S' THEN 's' "
+ " ELSE defaclobjtype END::\"char\" "
+ "ELSE NULL END",
dopt->binary_upgrade);
appendPQExpBuffer(query, "SELECT d.oid, d.tableoid, "
diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_dump.pl
index c61d95e817..31cf14a592 100644
--- a/src/bin/pg_dump/t/002_pg_dump.pl
+++ b/src/bin/pg_dump/t/002_pg_dump.pl
@@ -443,6 +443,24 @@ my %tests = (
},
},
+ 'ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role GRANT EXECUTE ON FUNCTIONS' => {
+ create_order => 15,
+ create_sql => 'ALTER DEFAULT PRIVILEGES
+ FOR ROLE regress_dump_test_role IN SCHEMA dump_test
+ GRANT EXECUTE ON FUNCTIONS TO regress_dump_test_role;',
+ regexp => qr/^
+ \QALTER DEFAULT PRIVILEGES \E
+ \QFOR ROLE regress_dump_test_role IN SCHEMA dump_test \E
+ \QGRANT ALL ON FUNCTIONS TO regress_dump_test_role;\E
+ /xm,
+ like =>
+ { %full_runs, %dump_test_schema_runs, section_post_data => 1, },
+ unlike => {
+ exclude_dump_test_schema => 1,
+ no_privs => 1,
+ },
+ },
+
'ALTER DEFAULT PRIVILEGES FOR ROLE regress_dump_test_role REVOKE' => {
create_order => 55,
create_sql => 'ALTER DEFAULT PRIVILEGES
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-19 03:19 Tom Lane <tgl@sss.pgh.pa.us>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
0 siblings, 2 replies; 26+ messages in thread
From: Tom Lane @ 2021-10-19 03:19 UTC (permalink / raw)
To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Bossart, Nathan <bossartn@amazon.com>; Michael Paquier <michael@paquier.xyz>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
Masahiko Sawada <sawada.mshk@gmail.com> writes:
> I've looked at the patch proposed you proposed. If we can depend on
> acldefault() being STRICT (which is legitimate to me), I think we
> don't need to build an expression depending on the caller (i.g.,
> is_default_acl). If acldefault() were to become not STRICT, we could
> detect it by regression tests. What do you think?
FWIW, I'm working on a refactoring of this logic that will bring the
acldefault() call into the getDefaultACLs code, which would mean that
we won't need that assumption anymore anyway. The code as I have it
produces SQL like
acldefault(CASE WHEN defaclobjtype = 'S'
THEN 's'::"char" ELSE defaclobjtype END, defaclrole) AS acldefault
and we could wrap the test-for-zero around that:
CASE WHEN defaclnamespace = 0 THEN
acldefault(CASE WHEN defaclobjtype = 'S'
THEN 's'::"char" ELSE defaclobjtype END, defaclrole)
ELSE NULL END AS acldefault
(although I think it might be better to write ELSE '{}' not ELSE NULL).
So I think we don't need to worry about whether acldefault() will stay
strict. This patch will only need to work in the back branches.
regards, tom lane
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-19 03:54 Bossart, Nathan <bossartn@amazon.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 26+ messages in thread
From: Bossart, Nathan @ 2021-10-19 03:54 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 10/18/21, 8:20 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> Masahiko Sawada <sawada.mshk@gmail.com> writes:
>> I've looked at the patch proposed you proposed. If we can depend on
>> acldefault() being STRICT (which is legitimate to me), I think we
>> don't need to build an expression depending on the caller (i.g.,
>> is_default_acl). If acldefault() were to become not STRICT, we could
>> detect it by regression tests. What do you think?
>
> FWIW, I'm working on a refactoring of this logic that will bring the
> acldefault() call into the getDefaultACLs code, which would mean that
> we won't need that assumption anymore anyway. The code as I have it
> produces SQL like
Nice!
> So I think we don't need to worry about whether acldefault() will stay
> strict. This patch will only need to work in the back branches.
This seems fine to me, too. I don't think relying on STRICT is any
better or worse than adding a flag for this one special case.
+ /*
+ * Since the default for a global entry is the hard-wired default
+ * ACL for the particular object type, we pass defaclobjtype except
+ * for the case of 'S' (DEFACLOBJ_SEQUENCE) where we need to
+ * transform it to 's' since acldefault() SQL-callable function
+ * handles 's' as a sequence. On the other hand, since the default
+ * for non-global entries is an empty ACL we pass NULL. This works
+ * because acldefault() is STRICT.
+ */
I'd split out the two special cases in the comment. What do you think
about something like the following?
/*
* Build the expression for determining the object type.
*
* While pg_default_acl uses 'S' for sequences, acldefault()
* uses 's', so we must transform 'S' to 's'.
*
* The default for a schema-local default ACL (i.e., entries
* in pg_default_acl with defaclnamespace != 0) is an empty
* ACL. We use NULL as the object type for those entries,
* which forces acldefault() to also return NULL because it is
* STRICT.
*/
+ create_sql => 'ALTER DEFAULT PRIVILEGES
+ FOR ROLE regress_dump_test_role IN SCHEMA dump_test
+ GRANT EXECUTE ON FUNCTIONS TO regress_dump_test_role;',
+ regexp => qr/^
+ \QALTER DEFAULT PRIVILEGES \E
+ \QFOR ROLE regress_dump_test_role IN SCHEMA dump_test \E
+ \QGRANT ALL ON FUNCTIONS TO regress_dump_test_role;\E
+ /xm,
It could be a bit confusing that create_sql uses "GRANT EXECUTE" but
we expect to see "GRANT ALL." IIUC this is correct, but maybe we
should use "GRANT ALL" in create_sql so that they match.
Nathan
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-19 05:51 Masahiko Sawada <sawada.mshk@gmail.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 1 reply; 26+ messages in thread
From: Masahiko Sawada @ 2021-10-19 05:51 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: Bossart, Nathan <bossartn@amazon.com>; Michael Paquier <michael@paquier.xyz>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On Tue, Oct 19, 2021 at 12:19 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Masahiko Sawada <sawada.mshk@gmail.com> writes:
> > I've looked at the patch proposed you proposed. If we can depend on
> > acldefault() being STRICT (which is legitimate to me), I think we
> > don't need to build an expression depending on the caller (i.g.,
> > is_default_acl). If acldefault() were to become not STRICT, we could
> > detect it by regression tests. What do you think?
>
> FWIW, I'm working on a refactoring of this logic that will bring the
> acldefault() call into the getDefaultACLs code, which would mean that
> we won't need that assumption anymore anyway. The code as I have it
> produces SQL like
>
> acldefault(CASE WHEN defaclobjtype = 'S'
> THEN 's'::"char" ELSE defaclobjtype END, defaclrole) AS acldefault
>
> and we could wrap the test-for-zero around that:
>
> CASE WHEN defaclnamespace = 0 THEN
> acldefault(CASE WHEN defaclobjtype = 'S'
> THEN 's'::"char" ELSE defaclobjtype END, defaclrole)
> ELSE NULL END AS acldefault
>
> (although I think it might be better to write ELSE '{}' not ELSE NULL).
>
> So I think we don't need to worry about whether acldefault() will stay
> strict. This patch will only need to work in the back branches.
+1
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-19 19:53 Tom Lane <tgl@sss.pgh.pa.us>
parent: Masahiko Sawada <sawada.mshk@gmail.com>
0 siblings, 1 reply; 26+ messages in thread
From: Tom Lane @ 2021-10-19 19:53 UTC (permalink / raw)
To: Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Bossart, Nathan <bossartn@amazon.com>; Michael Paquier <michael@paquier.xyz>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
... BTW, I think this patch is not correct yet. What I read in
catalogs.sgml is
... If a global entry is present then
it <emphasis>overrides</emphasis> the normal hard-wired default privileges
for the object type. A per-schema entry, if present, represents privileges
to be <emphasis>added to</emphasis> the global or hard-wired default privileges.
I didn't check the code, but if that last bit is correct, then non-global
entries aren't necessarily relative to the acldefault privileges either.
I kind of wonder now whether the existing behavior is correct for either
case. Why aren't we simply regurgitating the pg_default_acl entries
verbatim? That is, I think maybe we don't need the acldefault call at
all; we should just use null/empty as the starting ACL in all cases
when printing pg_default_acl entries. Like this:
buildACLQueries(acl_subquery, racl_subquery, initacl_subquery,
initracl_subquery, "defaclacl", "defaclrole",
"pip.initprivs",
- "CASE WHEN defaclobjtype = 'S' THEN 's' ELSE defaclobjtype END::\"char\"",
+ "NULL",
dopt->binary_upgrade);
I didn't test that. I suspect it will cause some regression test
changes, but will they be wrong?
regards, tom lane
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-19 21:01 Bossart, Nathan <bossartn@amazon.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 26+ messages in thread
From: Bossart, Nathan @ 2021-10-19 21:01 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Masahiko Sawada <sawada.mshk@gmail.com>; +Cc: Michael Paquier <michael@paquier.xyz>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 10/19/21, 12:54 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> I kind of wonder now whether the existing behavior is correct for either
> case. Why aren't we simply regurgitating the pg_default_acl entries
> verbatim? That is, I think maybe we don't need the acldefault call at
> all; we should just use null/empty as the starting ACL in all cases
> when printing pg_default_acl entries. Like this:
Hm. If we do this, then this command:
ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE ALL ON FUNCTIONS FROM PUBLIC;
is dumped as:
ALTER DEFAULT PRIVILEGES FOR ROLE myrole GRANT ALL ON FUNCTIONS TO myrole;
This command is effectively ignored when you apply it, as no entry is
added to pg_default_acl. I haven't looked too closely into what's
happening yet, but it does look like there is more to the story.
Nathan
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-19 21:58 Tom Lane <tgl@sss.pgh.pa.us>
parent: Bossart, Nathan <bossartn@amazon.com>
0 siblings, 1 reply; 26+ messages in thread
From: Tom Lane @ 2021-10-19 21:58 UTC (permalink / raw)
To: Bossart, Nathan <bossartn@amazon.com>; +Cc: Masahiko Sawada <sawada.mshk@gmail.com>; Michael Paquier <michael@paquier.xyz>; Neil Chen <carpenter.nail.cz@gmail.com>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
"Bossart, Nathan" <bossartn@amazon.com> writes:
> On 10/19/21, 12:54 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
>> I kind of wonder now whether the existing behavior is correct for either
>> case.
> Hm. If we do this, then this command:
> ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE ALL ON FUNCTIONS FROM PUBLIC;
> is dumped as:
> ALTER DEFAULT PRIVILEGES FOR ROLE myrole GRANT ALL ON FUNCTIONS TO myrole;
[ pokes at it some more... ] Yeah, I just didn't have my head screwed
on straight. We need the global entries to be dumped as deltas from
the proper object-type-specific ACL, while the non-global ones should be
dumped as grants only, which can be modeled as a delta from an empty
ACL. So the patch should be good as given (though maybe the comment
needs more work to clarify this). Sorry for the noise.
regards, tom lane
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-22 19:26 Tom Lane <tgl@sss.pgh.pa.us>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 26+ messages in thread
From: Tom Lane @ 2021-10-22 19:26 UTC (permalink / raw)
To: Neil Chen <carpenter.nail.cz@gmail.com>; +Cc: Bossart, Nathan <bossartn@amazon.com>; Masahiko Sawada <sawada.mshk@gmail.com>; Michael Paquier <michael@paquier.xyz>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
I wrote:
> [ pokes at it some more... ] Yeah, I just didn't have my head screwed
> on straight. We need the global entries to be dumped as deltas from
> the proper object-type-specific ACL, while the non-global ones should be
> dumped as grants only, which can be modeled as a delta from an empty
> ACL. So the patch should be good as given (though maybe the comment
> needs more work to clarify this). Sorry for the noise.
This was blocking some other work I'm doing on pg_dump, so I rewrote
the comment some more and pushed it.
regards, tom lane
^ permalink raw reply [nested|flat] 26+ messages in thread
* Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES
@ 2021-10-22 20:08 Bossart, Nathan <bossartn@amazon.com>
parent: Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 26+ messages in thread
From: Bossart, Nathan @ 2021-10-22 20:08 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; Neil Chen <carpenter.nail.cz@gmail.com>; +Cc: Masahiko Sawada <sawada.mshk@gmail.com>; Michael Paquier <michael@paquier.xyz>; Boris P. Korzun <drtr0jan@yandex.ru>; pgsql-bugs@lists.postgresql.org <pgsql-bugs@lists.postgresql.org>
On 10/22/21, 12:27 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote:
> This was blocking some other work I'm doing on pg_dump, so I rewrote
> the comment some more and pushed it.
Thanks!
Nathan
^ permalink raw reply [nested|flat] 26+ messages in thread
end of thread, other threads:[~2021-10-22 20:08 UTC | newest]
Thread overview: 26+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-03-24 20:38 Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES Boris P. Korzun <drtr0jan@yandex.ru>
2021-03-31 03:02 Re: Inconsistent behavior of pg_dump/pg_restore on DEFAULT PRIVILEGES Neil Chen <carpenter.nail.cz@gmail.com>
2021-03-31 03:30 ` Neil Chen <carpenter.nail.cz@gmail.com>
2021-04-02 14:09 ` Boris P. Korzun <drtr0jan@yandex.ru>
2021-09-21 05:04 ` Boris P. Korzun <drtr0jan@yandex.ru>
2021-09-22 01:30 ` Neil Chen <carpenter.nail.cz@gmail.com>
2021-10-01 14:13 ` Masahiko Sawada <sawada.mshk@gmail.com>
2021-10-14 00:36 ` Masahiko Sawada <sawada.mshk@gmail.com>
2021-10-14 02:55 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-10-14 05:22 ` Masahiko Sawada <sawada.mshk@gmail.com>
2021-10-14 07:53 ` Michael Paquier <michael@paquier.xyz>
2021-10-14 16:02 ` Bossart, Nathan <bossartn@amazon.com>
2021-10-14 16:13 ` Bossart, Nathan <bossartn@amazon.com>
2021-10-15 00:05 ` Masahiko Sawada <sawada.mshk@gmail.com>
2021-10-18 23:46 ` Bossart, Nathan <bossartn@amazon.com>
2021-10-19 02:04 ` Masahiko Sawada <sawada.mshk@gmail.com>
2021-10-19 03:19 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-10-19 03:54 ` Bossart, Nathan <bossartn@amazon.com>
2021-10-19 05:51 ` Masahiko Sawada <sawada.mshk@gmail.com>
2021-10-19 19:53 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-10-19 21:01 ` Bossart, Nathan <bossartn@amazon.com>
2021-10-19 21:58 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-10-22 19:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-10-22 20:08 ` Bossart, Nathan <bossartn@amazon.com>
2021-10-14 00:59 ` Masahiko Sawada <sawada.mshk@gmail.com>
2021-10-13 08:22 ` Boris Korzun <drtr0jan@yandex.ru>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox