diff options
author | Tom Lane <tgl@sss.pgh.pa.us> | 2020-07-11 13:36:50 -0400 |
---|---|---|
committer | Tom Lane <tgl@sss.pgh.pa.us> | 2020-07-11 13:36:50 -0400 |
commit | 4fdc559c88eb53ba12fc4c59a633d2bee0dbf8a2 (patch) | |
tree | 6de384bc3018edf1ce63673529e8433d0537908f /src/backend/utils/adt/arrayutils.c | |
parent | 0ecd36ee0e49250048f038c81fbc12b4102caa7e (diff) | |
download | postgresql-4fdc559c88eb53ba12fc4c59a633d2bee0dbf8a2.tar.gz postgresql-4fdc559c88eb53ba12fc4c59a633d2bee0dbf8a2.zip |
Avoid trying to restore table ACLs and per-column ACLs in parallel.
Parallel pg_restore has always supposed that ACL items for different
objects are independent and can be restored in parallel without
conflicts. However, there is one case where this fails: because
REVOKE on a table is defined to also revoke the privilege(s) at
column level, we can't restore per-column ACLs till after we restore
any table-level privileges on their table. Failure to honor this
restriction can lead to "tuple concurrently updated" errors during
parallel restore, or even to the per-column ACLs silently disappearing
because the table-level REVOKE is executed afterwards.
To fix, add a dependency from each column-level ACL item to its table's
ACL item, if there is one. Note that this doesn't fix the hazard
for pre-existing archive files, only for ones made with a corrected
pg_dump. Given that the bug's been there quite awhile without
field reports, I think this is acceptable.
This requires changing the API of pg_dump's dumpACL() function.
To keep its argument list from getting even longer, I removed the
"CatalogId objCatId" argument, which has been unused for ages.
Per report from Justin Pryzby. Back-patch to all supported branches.
Discussion: https://postgr.es/m/20200706050129.GW4107@telsasoft.com
Diffstat (limited to 'src/backend/utils/adt/arrayutils.c')
0 files changed, 0 insertions, 0 deletions