aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands/async.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-01-14 16:19:38 -0500
committerTom Lane <tgl@sss.pgh.pa.us>2021-01-14 16:19:38 -0500
commit8e396a773b80c72e5d5a0ca9755dffe043c97a05 (patch)
tree267517e897460090c282a8e53d9be5ddddc3380e /src/backend/commands/async.c
parentebfe2dbd6b624e2a428e14b7ee9322cc096f63f7 (diff)
downloadpostgresql-8e396a773b80c72e5d5a0ca9755dffe043c97a05.tar.gz
postgresql-8e396a773b80c72e5d5a0ca9755dffe043c97a05.zip
pg_dump: label PUBLICATION TABLE ArchiveEntries with an owner.
This is the same fix as commit 9eabfe300 applied to INDEX ATTACH entries, but for table-to-publication attachments. As in that case, even though the backend doesn't record "ownership" of the attachment, we still ought to label it in the dump archive with the role name that should run the ALTER PUBLICATION command. The existing behavior causes the ALTER to be done by the original role that started the restore; that will usually work fine, but there may be corner cases where it fails. The bulk of the patch is concerned with changing struct PublicationRelInfo to include a pointer to the associated PublicationInfo object, so that we can get the owner's name out of that when the time comes. While at it, I rewrote getPublicationTables() to do just one query of pg_publication_rel, not one per table. Back-patch to v10 where this code was introduced. Discussion: https://postgr.es/m/1165710.1610473242@sss.pgh.pa.us
Diffstat (limited to 'src/backend/commands/async.c')
0 files changed, 0 insertions, 0 deletions