pgsql: pg_verify_checksums: Message style improvements and NLS support
pg_verify_checksums: Message style improvements and NLS support The source code was already set up for NLS support, so just a nls.mk file needed to be added. Also, fix the old problem of putting the int64 format specifier right into the string, which breaks NLS. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/3e2ceb231ef0bbd04bb98aa3d3b58ebcac88c00a Modified Files -- src/bin/pg_verify_checksums/nls.mk| 4 src/bin/pg_verify_checksums/pg_verify_checksums.c | 16 2 files changed, 12 insertions(+), 8 deletions(-)
pgsql: pg_verify_checksums: Message style improvements and NLS support
pg_verify_checksums: Message style improvements and NLS support The source code was already set up for NLS support, so just a nls.mk file needed to be added. Also, fix the old problem of putting the int64 format specifier right into the string, which breaks NLS. Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/da793baca29fa83e3fb1eb09d2ef9aa863a02f7a Modified Files -- src/bin/pg_verify_checksums/nls.mk| 4 src/bin/pg_verify_checksums/pg_verify_checksums.c | 16 2 files changed, 12 insertions(+), 8 deletions(-)
pgsql: Avoid quadratic slowdown in regexp match/split functions.
Avoid quadratic slowdown in regexp match/split functions. regexp_matches, regexp_split_to_table and regexp_split_to_array all work by compiling a list of match positions as character offsets (NOT byte positions) in the source string. Formerly, they then used text_substr to extract the matched text; but in a multi-byte encoding, that counts the characters in the string, and the characters needed to reach the starting byte position, on every call. Accordingly, the performance degraded as the product of the input string length and the number of match positions, such that splitting a string of a few hundred kbytes could take many minutes. Repair by keeping the wide-character copy of the input string available (only in the case where encoding_max_length is not 1) after performing the match operation, and extracting substrings from that instead. This reduces the complexity to being linear in the number of result bytes, discounting the actual regexp match itself (which is not affected by this patch). In passing, remove cleanup using retail pfree() which was obsoleted by commit ff428cded (Feb 2008) which made cleanup of SRF multi-call contexts automatic. Also increase (to ~134 million) the maximum number of matches and provide an error message when it is reached. Backpatch all the way because this has been wrong forever. Analysis and patch by me; review by Kaiting Chen. Discussion: https://postgr.es/m/[email protected] see also https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/41cfae1f37187ecff15b4eba5b732ba350801228 Modified Files -- src/backend/utils/adt/regexp.c | 185 + 1 file changed, 131 insertions(+), 54 deletions(-)
pgsql: Avoid quadratic slowdown in regexp match/split functions.
Avoid quadratic slowdown in regexp match/split functions. regexp_matches, regexp_split_to_table and regexp_split_to_array all work by compiling a list of match positions as character offsets (NOT byte positions) in the source string. Formerly, they then used text_substr to extract the matched text; but in a multi-byte encoding, that counts the characters in the string, and the characters needed to reach the starting byte position, on every call. Accordingly, the performance degraded as the product of the input string length and the number of match positions, such that splitting a string of a few hundred kbytes could take many minutes. Repair by keeping the wide-character copy of the input string available (only in the case where encoding_max_length is not 1) after performing the match operation, and extracting substrings from that instead. This reduces the complexity to being linear in the number of result bytes, discounting the actual regexp match itself (which is not affected by this patch). In passing, remove cleanup using retail pfree() which was obsoleted by commit ff428cded (Feb 2008) which made cleanup of SRF multi-call contexts automatic. Also increase (to ~134 million) the maximum number of matches and provide an error message when it is reached. Backpatch all the way because this has been wrong forever. Analysis and patch by me; review by Kaiting Chen. Discussion: https://postgr.es/m/[email protected] see also https://postgr.es/m/[email protected] Branch -- REL9_3_STABLE Details --- https://git.postgresql.org/pg/commitdiff/861670369093b0bd5ddae336aed6e1e3c4ce8a13 Modified Files -- src/backend/utils/adt/regexp.c | 185 + 1 file changed, 131 insertions(+), 54 deletions(-)
pgsql: Avoid quadratic slowdown in regexp match/split functions.
Avoid quadratic slowdown in regexp match/split functions. regexp_matches, regexp_split_to_table and regexp_split_to_array all work by compiling a list of match positions as character offsets (NOT byte positions) in the source string. Formerly, they then used text_substr to extract the matched text; but in a multi-byte encoding, that counts the characters in the string, and the characters needed to reach the starting byte position, on every call. Accordingly, the performance degraded as the product of the input string length and the number of match positions, such that splitting a string of a few hundred kbytes could take many minutes. Repair by keeping the wide-character copy of the input string available (only in the case where encoding_max_length is not 1) after performing the match operation, and extracting substrings from that instead. This reduces the complexity to being linear in the number of result bytes, discounting the actual regexp match itself (which is not affected by this patch). In passing, remove cleanup using retail pfree() which was obsoleted by commit ff428cded (Feb 2008) which made cleanup of SRF multi-call contexts automatic. Also increase (to ~134 million) the maximum number of matches and provide an error message when it is reached. Backpatch all the way because this has been wrong forever. Analysis and patch by me; review by Kaiting Chen. Discussion: https://postgr.es/m/[email protected] see also https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/bc552b322fd954f8d87aef850b64e0d9ed376cfa Modified Files -- src/backend/utils/adt/regexp.c | 182 + 1 file changed, 129 insertions(+), 53 deletions(-)
pgsql: Avoid quadratic slowdown in regexp match/split functions.
Avoid quadratic slowdown in regexp match/split functions. regexp_matches, regexp_split_to_table and regexp_split_to_array all work by compiling a list of match positions as character offsets (NOT byte positions) in the source string. Formerly, they then used text_substr to extract the matched text; but in a multi-byte encoding, that counts the characters in the string, and the characters needed to reach the starting byte position, on every call. Accordingly, the performance degraded as the product of the input string length and the number of match positions, such that splitting a string of a few hundred kbytes could take many minutes. Repair by keeping the wide-character copy of the input string available (only in the case where encoding_max_length is not 1) after performing the match operation, and extracting substrings from that instead. This reduces the complexity to being linear in the number of result bytes, discounting the actual regexp match itself (which is not affected by this patch). In passing, remove cleanup using retail pfree() which was obsoleted by commit ff428cded (Feb 2008) which made cleanup of SRF multi-call contexts automatic. Also increase (to ~134 million) the maximum number of matches and provide an error message when it is reached. Backpatch all the way because this has been wrong forever. Analysis and patch by me; review by Kaiting Chen. Discussion: https://postgr.es/m/[email protected] see also https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/450b247415125e08821dfbb68b0a15a4f0f7eb22 Modified Files -- src/backend/utils/adt/regexp.c | 185 + 1 file changed, 131 insertions(+), 54 deletions(-)
pgsql: Avoid quadratic slowdown in regexp match/split functions.
Avoid quadratic slowdown in regexp match/split functions. regexp_matches, regexp_split_to_table and regexp_split_to_array all work by compiling a list of match positions as character offsets (NOT byte positions) in the source string. Formerly, they then used text_substr to extract the matched text; but in a multi-byte encoding, that counts the characters in the string, and the characters needed to reach the starting byte position, on every call. Accordingly, the performance degraded as the product of the input string length and the number of match positions, such that splitting a string of a few hundred kbytes could take many minutes. Repair by keeping the wide-character copy of the input string available (only in the case where encoding_max_length is not 1) after performing the match operation, and extracting substrings from that instead. This reduces the complexity to being linear in the number of result bytes, discounting the actual regexp match itself (which is not affected by this patch). In passing, remove cleanup using retail pfree() which was obsoleted by commit ff428cded (Feb 2008) which made cleanup of SRF multi-call contexts automatic. Also increase (to ~134 million) the maximum number of matches and provide an error message when it is reached. Backpatch all the way because this has been wrong forever. Analysis and patch by me; review by Kaiting Chen. Discussion: https://postgr.es/m/[email protected] see also https://postgr.es/m/[email protected] Branch -- REL9_4_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2ba7c4e6c4624fdb6230b060625a494bc93e0b9b Modified Files -- src/backend/utils/adt/regexp.c | 185 + 1 file changed, 131 insertions(+), 54 deletions(-)
pgsql: Avoid quadratic slowdown in regexp match/split functions.
Avoid quadratic slowdown in regexp match/split functions. regexp_matches, regexp_split_to_table and regexp_split_to_array all work by compiling a list of match positions as character offsets (NOT byte positions) in the source string. Formerly, they then used text_substr to extract the matched text; but in a multi-byte encoding, that counts the characters in the string, and the characters needed to reach the starting byte position, on every call. Accordingly, the performance degraded as the product of the input string length and the number of match positions, such that splitting a string of a few hundred kbytes could take many minutes. Repair by keeping the wide-character copy of the input string available (only in the case where encoding_max_length is not 1) after performing the match operation, and extracting substrings from that instead. This reduces the complexity to being linear in the number of result bytes, discounting the actual regexp match itself (which is not affected by this patch). In passing, remove cleanup using retail pfree() which was obsoleted by commit ff428cded (Feb 2008) which made cleanup of SRF multi-call contexts automatic. Also increase (to ~134 million) the maximum number of matches and provide an error message when it is reached. Backpatch all the way because this has been wrong forever. Analysis and patch by me; review by Kaiting Chen. Discussion: https://postgr.es/m/[email protected] see also https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/f6f61d937bfddbe2a5f6a37bc26a0587117d7837 Modified Files -- src/backend/utils/adt/regexp.c | 182 + 1 file changed, 129 insertions(+), 53 deletions(-)
pgsql: Avoid quadratic slowdown in regexp match/split functions.
Avoid quadratic slowdown in regexp match/split functions. regexp_matches, regexp_split_to_table and regexp_split_to_array all work by compiling a list of match positions as character offsets (NOT byte positions) in the source string. Formerly, they then used text_substr to extract the matched text; but in a multi-byte encoding, that counts the characters in the string, and the characters needed to reach the starting byte position, on every call. Accordingly, the performance degraded as the product of the input string length and the number of match positions, such that splitting a string of a few hundred kbytes could take many minutes. Repair by keeping the wide-character copy of the input string available (only in the case where encoding_max_length is not 1) after performing the match operation, and extracting substrings from that instead. This reduces the complexity to being linear in the number of result bytes, discounting the actual regexp match itself (which is not affected by this patch). In passing, remove cleanup using retail pfree() which was obsoleted by commit ff428cded (Feb 2008) which made cleanup of SRF multi-call contexts automatic. Also increase (to ~134 million) the maximum number of matches and provide an error message when it is reached. Backpatch all the way because this has been wrong forever. Analysis and patch by me; review by Kaiting Chen. Discussion: https://postgr.es/m/[email protected] see also https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c8ea87e4bd950572cba4575e9a62284cebf85ac5 Modified Files -- src/backend/utils/adt/regexp.c | 182 + 1 file changed, 129 insertions(+), 53 deletions(-)
pgsql: Rework option set of oid2name
Rework option set of oid2name oid2name has done little effort to keep an interface consistent with other binary utilities: - -H was used instead of -h/-host. This option is now marked as deprecated, still its output is accepted to be backward-compatible. - -P has been removed from the code, and was still documented. - All options gain long aliases, making connection options more similar to other binaries. - Document environment variables which could be used: PGHOST, PGPORT and PGUSER. A basic set of TAP tests is added on the way, and documentation is cleaned up to be more consistent with other things. Author: Tatsuro Yamada Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/1aaf532deabfa356c99abc80fc78d988ad1f1355 Modified Files -- contrib/oid2name/.gitignore | 2 + contrib/oid2name/Makefile | 6 +++ contrib/oid2name/oid2name.c | 114 +++- contrib/oid2name/t/001_basic.pl | 12 + doc/src/sgml/oid2name.sgml | 81 5 files changed, 146 insertions(+), 69 deletions(-)
pgsql: Rework option set of vacuumlo
Rework option set of vacuumlo Like oid2name, vacuumlo has been lacking consistency with other utilities for its options: - Connection options gain long aliases. - Document environment variables which could be used: PGHOST, PGPORT and PGUSER. Documentation and code is reordered to be more consistent. A basic set of TAP tests has been added while on it. Author: Tatsuro Yamada Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bfea331a5e1b993d22071fc1696e6e8811d2d0d4 Modified Files -- contrib/vacuumlo/.gitignore | 2 ++ contrib/vacuumlo/Makefile | 6 contrib/vacuumlo/t/001_basic.pl | 9 + contrib/vacuumlo/vacuumlo.c | 79 - doc/src/sgml/vacuumlo.sgml | 39 +--- 5 files changed, 98 insertions(+), 37 deletions(-)
pgsql: postgres_fdw: don't push ORDER BY with no vars (bug #15352)
postgres_fdw: don't push ORDER BY with no vars (bug #15352) Commit aa09cd242 changed a condition in find_em_expr_for_rel from being a bms_equal comparison of relids to bms_is_subset, in order to support order by clauses on foreign joins. But this also allows through the degenerate case of expressions with no Vars at all (and hence empty relids), including integer constants which will be parsed unexpectedly on the remote (viz. "ERROR: ORDER BY position 0 is not in select list" as in the bug report). Repair by adding an additional !bms_is_empty test. Backpatch through to 9.6 where the aforementioned change was made. Per bug #15352 from Maksym Boguk; analysis and patch by me. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/639bdbb96fed7f8975111bf8081172fd8c7f623d Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: postgres_fdw: don't push ORDER BY with no vars (bug #15352)
postgres_fdw: don't push ORDER BY with no vars (bug #15352) Commit aa09cd242 changed a condition in find_em_expr_for_rel from being a bms_equal comparison of relids to bms_is_subset, in order to support order by clauses on foreign joins. But this also allows through the degenerate case of expressions with no Vars at all (and hence empty relids), including integer constants which will be parsed unexpectedly on the remote (viz. "ERROR: ORDER BY position 0 is not in select list" as in the bug report). Repair by adding an additional !bms_is_empty test. Backpatch through to 9.6 where the aforementioned change was made. Per bug #15352 from Maksym Boguk; analysis and patch by me. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8bc6a301b21cc189f5141c45be93938215e21fb7 Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: postgres_fdw: don't push ORDER BY with no vars (bug #15352)
postgres_fdw: don't push ORDER BY with no vars (bug #15352) Commit aa09cd242 changed a condition in find_em_expr_for_rel from being a bms_equal comparison of relids to bms_is_subset, in order to support order by clauses on foreign joins. But this also allows through the degenerate case of expressions with no Vars at all (and hence empty relids), including integer constants which will be parsed unexpectedly on the remote (viz. "ERROR: ORDER BY position 0 is not in select list" as in the bug report). Repair by adding an additional !bms_is_empty test. Backpatch through to 9.6 where the aforementioned change was made. Per bug #15352 from Maksym Boguk; analysis and patch by me. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/64eed263ac474433d17f05b23df3018a38e71fca Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
pgsql: postgres_fdw: don't push ORDER BY with no vars (bug #15352)
postgres_fdw: don't push ORDER BY with no vars (bug #15352) Commit aa09cd242 changed a condition in find_em_expr_for_rel from being a bms_equal comparison of relids to bms_is_subset, in order to support order by clauses on foreign joins. But this also allows through the degenerate case of expressions with no Vars at all (and hence empty relids), including integer constants which will be parsed unexpectedly on the remote (viz. "ERROR: ORDER BY position 0 is not in select list" as in the bug report). Repair by adding an additional !bms_is_empty test. Backpatch through to 9.6 where the aforementioned change was made. Per bug #15352 from Maksym Boguk; analysis and patch by me. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/bf2d0462cd735f76bcf6eb8b399723674b2221ef Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
Re: pgsql: Rework option set of vacuumlo
Michael Paquier writes: > Documentation and code is reordered to be more consistent. A basic set > of TAP tests has been added while on it. It'd be even better if these tests passed. For me, not so much: $ make check ... t/001_basic.pl .. # Looks like your test exited with 2 before it could output anything. t/001_basic.pl .. Dubious, test returned 2 (wstat 512, 0x200) Failed 8/8 subtests Test Summary Report --- t/001_basic.pl (Wstat: 512 Tests: 0 Failed: 0) Non-zero exit status: 2 Parse errors: Bad plan. You planned 8 tests but ran 0. Files=1, Tests=0, 0 wallclock secs ( 0.02 usr 0.01 sys + 0.06 cusr 0.01 csys = 0.10 CPU) Result: FAIL and the log file says # Running: oid2name --help Command 'oid2name' not found in /home/postgres/testversion/bin, /home/postgres/t estversion/bin, /usr/local/autoconf-2.69/bin, /home/postgres/bin, /usr/lib64/qt- 3.3/bin, /usr/lib64/ccache, /usr/local/bin, /bin, /usr/bin, /usr/local/sbin, /us r/sbin, /sbin at /home/postgres/pgsql/contrib/oid2name/../../src/test/perl/TestL ib.pm line 414 # Looks like your test exited with 2 before it could output anything. Similarly for the new vacuumlo tests. This is also why the cfbot is unhappy. Oddly, the buildfarm is not. I think the reason why not is that the buildfarm does "make installcheck" in contrib, and it first does "make install" in contrib, so that there's a copy of oid2name to be found in the PATH. But "make check" ought to be testing the executable in the temporary installation tree, and it's not. Digging, this is because the "make check" processing isn't actually installing oid2name (resp. vacuumlo) into the temp installation tree :-(. I don't think this is the fault of your tests, exactly --- there's something wrong in the existing make rules. I'm not sure what though. EXTRA_INSTALL should be getting set, according to pgxs.mk: temp-install: EXTRA_INSTALL+=$(subdir) but it evidently isn't. regards, tom lane
Re: pgsql: Rework option set of vacuumlo
I wrote: > Digging, this is because the "make check" processing isn't actually > installing oid2name (resp. vacuumlo) into the temp installation tree :-(. > > I don't think this is the fault of your tests, exactly --- there's > something wrong in the existing make rules. I'm not sure what though. > EXTRA_INSTALL should be getting set, according to pgxs.mk: > temp-install: EXTRA_INSTALL+=$(subdir) > but it evidently isn't. Oh! The reason why not is that that line is inside "ifdef REGRESS", and these subdirectories have no REGRESS tests. So we should move that out to where it will apply regardless of that. Will fix. regards, tom lane
pgsql: Include contrib modules in the temp installation even without RE
Include contrib modules in the temp installation even without REGRESS. Now that we have TAP tests, a contrib module may have something useful to do in "make check" even if it has no pg_regress-style regression scripts, and hence no REGRESS setting. But the TAP tests will fail, or else test the wrong installed files, unless we install the contrib module into the temp installation. So move the bit about adding to EXTRA_INSTALL so that it applies regardless. We might want this in back branches in future, but for the moment I only risked adding it to v11. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/8ede2691d65e4c0aa1ae23453b5bed63f9a36254 Modified Files -- src/makefiles/pgxs.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
pgsql: Include contrib modules in the temp installation even without RE
Include contrib modules in the temp installation even without REGRESS. Now that we have TAP tests, a contrib module may have something useful to do in "make check" even if it has no pg_regress-style regression scripts, and hence no REGRESS setting. But the TAP tests will fail, or else test the wrong installed files, unless we install the contrib module into the temp installation. So move the bit about adding to EXTRA_INSTALL so that it applies regardless. We might want this in back branches in future, but for the moment I only risked adding it to v11. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/42e61c7748eb36b75a05bd0a9a35c370c70a86c8 Modified Files -- src/makefiles/pgxs.mk | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Re: pgsql: Rework option set of vacuumlo
On Tue, Aug 28, 2018 at 05:08:25PM -0400, Tom Lane wrote: > I wrote: >> Digging, this is because the "make check" processing isn't actually >> installing oid2name (resp. vacuumlo) into the temp installation tree :-(. >> >> I don't think this is the fault of your tests, exactly --- there's >> something wrong in the existing make rules. I'm not sure what though. >> EXTRA_INSTALL should be getting set, according to pgxs.mk: >> temp-install: EXTRA_INSTALL+=$(subdir) >> but it evidently isn't. > > Oh! The reason why not is that that line is inside "ifdef REGRESS", > and these subdirectories have no REGRESS tests. So we should move > that out to where it will apply regardless of that. Will fix. Yes, I was going to send a patch along the same lines as what you have just committed. Thanks! It looks that the binary was installed in my own PATH, so I did not notice it. This should definitely get back-patched in my opinion, I have similar problems with pg_rewind tests of 9.3 and 9.4 that I still maintain out of the core tree, where the main binary needs to be installed first. In this case I just used some Makefile trick. -- Michael signature.asc Description: PGP signature
Re: pgsql: Rework option set of vacuumlo
Michael Paquier writes: > On Tue, Aug 28, 2018 at 05:08:25PM -0400, Tom Lane wrote: >> Oh! The reason why not is that that line is inside "ifdef REGRESS", >> and these subdirectories have no REGRESS tests. So we should move >> that out to where it will apply regardless of that. Will fix. > Yes, I was going to send a patch along the same lines as what you have > just committed. Thanks! It looks that the binary was installed in my > own PATH, so I did not notice it. > This should definitely get back-patched in my opinion, I have similar > problems with pg_rewind tests of 9.3 and 9.4 that I still maintain out > of the core tree, where the main binary needs to be installed first. In > this case I just used some Makefile trick. I didn't want to backpatch further than v11 without a test case that would work in those branches, and I lacked one. If you've got out-of-core code you could verify it with, please do that and back-patch further. regards, tom lane
pgsql: Code review for pg_dump's handling of ALTER INDEX ATTACH PARTITI
Code review for pg_dump's handling of ALTER INDEX ATTACH PARTITION. Ensure the TOC entry is marked with the correct schema, so that its name is as unique as the index's is. Fix the dependencies: we want dependencies from this TOC entry to the two indexes it depends on, and we don't care (at least not for this purpose) what order the indexes are created in. Also, add dependencies on the indexes' underlying tables. Those might seem pointless given the index dependencies, but they are helpful to cue parallel restore to avoid running the ATTACH PARTITION in parallel with other DDL on the same tables. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/18f6258e5ee8ea8d9c06bd58655cf8c6e4f1016f Modified Files -- src/bin/pg_dump/common.c | 24 +++- src/bin/pg_dump/pg_dump.c | 5 +++-- 2 files changed, 22 insertions(+), 7 deletions(-)
pgsql: Make pg_restore's identify_locking_dependencies() more bulletpro
Make pg_restore's identify_locking_dependencies() more bulletproof. This function had a blacklist of dump object types that it believed needed exclusive lock ... but we hadn't maintained that, so that it was missing ROW SECURITY, POLICY, and INDEX ATTACH items, all of which need (or should be treated as needing) exclusive lock. Since the same oversight seems likely in future, let's reverse the sense of the test so that the code has a whitelist of safe object types; better to wrongly assume a command can't be run in parallel than the opposite. Currently the only POST_DATA object type that's safe is CREATE INDEX ... and that list hasn't changed in a long time. Back-patch to 9.5 where RLS came in. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/aac21f11df0dbe6ee32ac8151bd1ea2c7987f683 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-)
pgsql: Make pg_restore's identify_locking_dependencies() more bulletpro
Make pg_restore's identify_locking_dependencies() more bulletproof. This function had a blacklist of dump object types that it believed needed exclusive lock ... but we hadn't maintained that, so that it was missing ROW SECURITY, POLICY, and INDEX ATTACH items, all of which need (or should be treated as needing) exclusive lock. Since the same oversight seems likely in future, let's reverse the sense of the test so that the code has a whitelist of safe object types; better to wrongly assume a command can't be run in parallel than the opposite. Currently the only POST_DATA object type that's safe is CREATE INDEX ... and that list hasn't changed in a long time. Back-patch to 9.5 where RLS came in. Discussion: https://postgr.es/m/[email protected] Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/e2841d399a89636b8411d9985c468f202cfd0171 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-)
pgsql: Make pg_restore's identify_locking_dependencies() more bulletpro
Make pg_restore's identify_locking_dependencies() more bulletproof. This function had a blacklist of dump object types that it believed needed exclusive lock ... but we hadn't maintained that, so that it was missing ROW SECURITY, POLICY, and INDEX ATTACH items, all of which need (or should be treated as needing) exclusive lock. Since the same oversight seems likely in future, let's reverse the sense of the test so that the code has a whitelist of safe object types; better to wrongly assume a command can't be run in parallel than the opposite. Currently the only POST_DATA object type that's safe is CREATE INDEX ... and that list hasn't changed in a long time. Back-patch to 9.5 where RLS came in. Discussion: https://postgr.es/m/[email protected] Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/49841edcc6440ccfe8cab2a2f478edadc9a0b266 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-)
pgsql: Code review for pg_dump's handling of ALTER INDEX ATTACH PARTITI
Code review for pg_dump's handling of ALTER INDEX ATTACH PARTITION. Ensure the TOC entry is marked with the correct schema, so that its name is as unique as the index's is. Fix the dependencies: we want dependencies from this TOC entry to the two indexes it depends on, and we don't care (at least not for this purpose) what order the indexes are created in. Also, add dependencies on the indexes' underlying tables. Those might seem pointless given the index dependencies, but they are helpful to cue parallel restore to avoid running the ATTACH PARTITION in parallel with other DDL on the same tables. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/8cff4f5348d075e063100071013f00a900c32b0f Modified Files -- src/bin/pg_dump/common.c | 24 +++- src/bin/pg_dump/pg_dump.c | 5 +++-- 2 files changed, 22 insertions(+), 7 deletions(-)
pgsql: Make pg_restore's identify_locking_dependencies() more bulletpro
Make pg_restore's identify_locking_dependencies() more bulletproof. This function had a blacklist of dump object types that it believed needed exclusive lock ... but we hadn't maintained that, so that it was missing ROW SECURITY, POLICY, and INDEX ATTACH items, all of which need (or should be treated as needing) exclusive lock. Since the same oversight seems likely in future, let's reverse the sense of the test so that the code has a whitelist of safe object types; better to wrongly assume a command can't be run in parallel than the opposite. Currently the only POST_DATA object type that's safe is CREATE INDEX ... and that list hasn't changed in a long time. Back-patch to 9.5 where RLS came in. Discussion: https://postgr.es/m/[email protected] Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/e0a0cc28d0829bea5d339fc2db6ac26ea13d5ab4 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-)
pgsql: Make pg_restore's identify_locking_dependencies() more bulletpro
Make pg_restore's identify_locking_dependencies() more bulletproof. This function had a blacklist of dump object types that it believed needed exclusive lock ... but we hadn't maintained that, so that it was missing ROW SECURITY, POLICY, and INDEX ATTACH items, all of which need (or should be treated as needing) exclusive lock. Since the same oversight seems likely in future, let's reverse the sense of the test so that the code has a whitelist of safe object types; better to wrongly assume a command can't be run in parallel than the opposite. Currently the only POST_DATA object type that's safe is CREATE INDEX ... and that list hasn't changed in a long time. Back-patch to 9.5 where RLS came in. Discussion: https://postgr.es/m/[email protected] Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/97aa524f18c0c5d4f800a6b37bb340890dba3224 Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 20 ++-- 1 file changed, 14 insertions(+), 6 deletions(-)
