aboutsummaryrefslogtreecommitdiff
path: root/src/test/modules/commit_ts/sql/commit_timestamp.sql
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2020-07-11 13:36:50 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2020-07-11 13:36:50 -0400
commitea9125304dc6e90eabad165bd120eb1e667525d4 (patch)
tree5be3fd34f1a00b928b2f9554d4ade98210cfba81 /src/test/modules/commit_ts/sql/commit_timestamp.sql
parent64fe120b57c6a928a527880476e9882b9bf7ae8a (diff)
downloadpostgresql-ea9125304dc6e90eabad165bd120eb1e667525d4.tar.gz
postgresql-ea9125304dc6e90eabad165bd120eb1e667525d4.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/test/modules/commit_ts/sql/commit_timestamp.sql')
0 files changed, 0 insertions, 0 deletions