Skip to content

Commit 4f16152

Browse files
committed
Fix omission of column-level privileges in selective pg_restore.
In a selective restore, ACLs for a table should be dumped if the table is selected to be dumped. However, if the table has both table-level and column-level ACLs, only the table-level ACL was restored. This happened because _tocEntryRequired assumed that an ACL could have only one dependency (the one on its table), and punted if there was more than one. But since commit ea91253, column-level ACLs also depend on the table-level ACL if any, to ensure correct ordering in parallel restores. To fix, adjust the logic in _tocEntryRequired to ignore dependencies on ACLs. I extended a test case in 002_pg_dump.pl so that it purports to test for this; but in fact the test passes even without the fix. That's because this bug only manifests during a selective restore, while the scenarios 002_pg_dump.pl tests include only selective dumps. Perhaps somebody would like to extend the script so that it can test scenarios including selective restore, but I'm not touching that. Euler Taveira and Tom Lane, per report from Kong Man. Back-patch to all supported branches. Discussion: https://postgr.es/m/DM4PR11MB73976902DBBA10B1D652F9498B06A@DM4PR11MB7397.namprd11.prod.outlook.com
1 parent 7a310ca commit 4f16152

File tree

2 files changed

+27
-6
lines changed

2 files changed

+27
-6
lines changed

src/bin/pg_dump/pg_backup_archiver.c

Lines changed: 22 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -2912,7 +2912,10 @@ _tocEntryRequired(TocEntry *te, teSection curSection, ArchiveHandle *AH)
29122912
* TOC entry types only if their parent object is being restored.
29132913
* Without selectivity options, we let through everything in the
29142914
* archive. Note there may be such entries with no parent, eg
2915-
* non-default ACLs for built-in objects.
2915+
* non-default ACLs for built-in objects. Also, we make
2916+
* per-column ACLs additionally depend on the table's ACL if any
2917+
* to ensure correct restore order, so those dependencies should
2918+
* be ignored in this check.
29162919
*
29172920
* This code depends on the parent having been marked already,
29182921
* which should be the case; if it isn't, perhaps due to
@@ -2923,8 +2926,24 @@ _tocEntryRequired(TocEntry *te, teSection curSection, ArchiveHandle *AH)
29232926
* But it's hard to tell which of their dependencies is the one to
29242927
* consult.
29252928
*/
2926-
if (te->nDeps != 1 ||
2927-
TocIDRequired(AH, te->dependencies[0]) == 0)
2929+
bool dumpthis = false;
2930+
int i;
2931+
2932+
for (i = 0; i < te->nDeps; i++)
2933+
{
2934+
TocEntry *pte = getTocEntryByDumpId(AH, te->dependencies[i]);
2935+
2936+
if (!pte)
2937+
continue; /* probably shouldn't happen */
2938+
if (strcmp(pte->desc, "ACL") == 0)
2939+
continue; /* ignore dependency on another ACL */
2940+
if (pte->reqs == 0)
2941+
continue; /* this object isn't marked, so ignore it */
2942+
/* Found a parent to be dumped, so we want to dump this too */
2943+
dumpthis = true;
2944+
break;
2945+
}
2946+
if (!dumpthis)
29282947
return 0;
29292948
}
29302949
}

src/bin/pg_dump/t/002_pg_dump.pl

Lines changed: 5 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -3105,11 +3105,13 @@
31053105
31063106
'GRANT SELECT ON TABLE measurement' => {
31073107
create_order => 91,
3108-
create_sql => 'GRANT SELECT ON
3109-
TABLE dump_test.measurement
3108+
create_sql => 'GRANT SELECT ON TABLE dump_test.measurement
3109+
TO regress_dump_test_role;
3110+
GRANT SELECT(city_id) ON TABLE dump_test.measurement
31103111
TO regress_dump_test_role;',
31113112
regexp =>
3112-
qr/^GRANT SELECT ON TABLE dump_test.measurement TO regress_dump_test_role;/m,
3113+
qr/^\QGRANT SELECT ON TABLE dump_test.measurement TO regress_dump_test_role;\E\n.*
3114+
^\QGRANT SELECT(city_id) ON TABLE dump_test.measurement TO regress_dump_test_role;\E/xms,
31133115
like =>
31143116
{ %full_runs, %dump_test_schema_runs, section_pre_data => 1, },
31153117
unlike => {

0 commit comments

Comments
 (0)