pgsql: doc: Add link from pg_dump --encoding to supported encodings
doc: Add link from pg_dump --encoding to supported encodings Reported-by: Lee Dong Wook Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/64fe120b57c6a928a527880476e9882b9bf7ae8a Modified Files -- doc/src/sgml/ref/pg_dump.sgml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: Avoid trying to restore table ACLs and per-column ACLs in parall
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/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/ea9125304dc6e90eabad165bd120eb1e667525d4 Modified Files -- src/bin/pg_dump/common.c| 2 +- src/bin/pg_dump/pg_backup.h | 6 +++ src/bin/pg_dump/pg_dump.c | 91 - 3 files changed, 64 insertions(+), 35 deletions(-)
pgsql: Avoid trying to restore table ACLs and per-column ACLs in parall
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/[email protected] Branch -- REL_12_STABLE Details --- https://git.postgresql.org/pg/commitdiff/5fea14f4b2c5ca4e4d9def92b17e50fcfbaf3468 Modified Files -- src/bin/pg_dump/common.c| 2 +- src/bin/pg_dump/pg_backup.h | 6 +++ src/bin/pg_dump/pg_dump.c | 91 - 3 files changed, 64 insertions(+), 35 deletions(-)
pgsql: Avoid trying to restore table ACLs and per-column ACLs in parall
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/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4fdc559c88eb53ba12fc4c59a633d2bee0dbf8a2 Modified Files -- src/bin/pg_dump/common.c| 2 +- src/bin/pg_dump/pg_backup.h | 6 src/bin/pg_dump/pg_dump.c | 81 + 3 files changed, 59 insertions(+), 30 deletions(-)
pgsql: Avoid trying to restore table ACLs and per-column ACLs in parall
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/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2d43c3057c971e63d1b7389d830dabe6c3ea368a Modified Files -- src/bin/pg_dump/common.c| 2 +- src/bin/pg_dump/pg_backup.h | 6 src/bin/pg_dump/pg_dump.c | 79 + 3 files changed, 58 insertions(+), 29 deletions(-)
pgsql: Avoid trying to restore table ACLs and per-column ACLs in parall
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/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/db820b9a9d004213b7a372dc0ba2e014ce1d2a73 Modified Files -- src/bin/pg_dump/common.c| 2 +- src/bin/pg_dump/pg_backup.h | 6 src/bin/pg_dump/pg_dump.c | 77 + 3 files changed, 57 insertions(+), 28 deletions(-)
pgsql: Avoid trying to restore table ACLs and per-column ACLs in parall
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/[email protected] Branch -- REL_13_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bc9aaac1a188cac11b1ebb04047de3db71257785 Modified Files -- src/bin/pg_dump/common.c| 2 +- src/bin/pg_dump/pg_backup.h | 6 +++ src/bin/pg_dump/pg_dump.c | 91 - 3 files changed, 64 insertions(+), 35 deletions(-)
pgsql: Avoid trying to restore table ACLs and per-column ACLs in parall
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/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/303322c5a4a867e205577377905409a21cc074e6 Modified Files -- src/bin/pg_dump/common.c| 2 +- src/bin/pg_dump/pg_backup.h | 6 src/bin/pg_dump/pg_dump.c | 79 + 3 files changed, 58 insertions(+), 29 deletions(-)
pgsql: Avoid useless buffer allocations during binary COPY FROM.
Avoid useless buffer allocations during binary COPY FROM. The raw_buf and line_buf buffers aren't used when reading binary format, so skip allocating them. raw_buf is 64K so that seems like a worthwhile savings. An unused line_buf only wastes 1K, but as long as we're checking it's free to avoid allocating that too. Bharath Rupireddy, tweaked a bit by me Discussion: https://postgr.es/m/calj2acxcckagpy0whowqrj4opjvdntssgpgczvufqu5z0cx...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/cd22d3cdb9bd9963c694c01a8c0232bbae3ddcfb Modified Files -- src/backend/commands/copy.c | 20 +++- 1 file changed, 15 insertions(+), 5 deletions(-)
