[COMMITTERS] Migration to pglister - Before
Greetings, We will be migrating these lists to pglister in the next few minutes. This final email on the old list system is intended to let you know that future emails will have different headers and you will need to adjust your filters. The changes which we expect to be most significant to users can be found on the wiki here: https://wiki.postgresql.org/wiki/PGLister_Announce Once the migration of these lists is complete, an 'after' email will be sent out. Thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > Do we care about people upgrading to unreleased versions? We could do > > nothing, document it in the release notes, or ??? > > Do nothing. Agreed. Not much we can do there. Thanks! Stephen signature.asc Description: Digital signature
[COMMITTERS] pgsql: Remove inbound links to sql-createuser
Remove inbound links to sql-createuser CREATE USER is an alias for CREATE ROLE, not its own command any longer, so clean up references to the 'sql-createuser' link to go to 'sql-createrole' instead. In passing, change a few cases of 'CREATE USER' to be 'CREATE ROLE ... LOGIN'. The remaining cases appear reasonable and also mention the distinction between 'CREATE ROLE' and 'CREATE USER'. Also, don't say CREATE USER "assumes" LOGIN, but rather "includes". Patch-by: David G. Johnston, with assumes->includes by me. Discussion: https://postgr.es/m/CAKFQuwYrbhKV8hH4TEABrDRBwf=gKremF=mlpq6x2ygqxgf...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0fe2780db4876cb38f9f914c855a54db7c141e2f Modified Files -- doc/src/sgml/client-auth.sgml | 4 ++-- doc/src/sgml/ref/create_database.sgml | 2 +- doc/src/sgml/user-manag.sgml | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix ordering in pg_dump of GRANTs
Fix ordering in pg_dump of GRANTs The order in which GRANTs are output is important as GRANTs which have been GRANT'd by individuals via WITH GRANT OPTION GRANTs have to come after the GRANT which included the WITH GRANT OPTION. This happens naturally in the backend during normal operation as we only change existing ACLs in-place, only add new ACLs to the end, and when removing an ACL we remove any which depend on it also. Also, adjust the comments in acl.h to make this clear. Unfortunately, the updates to pg_dump to handle initial privileges involved pulling apart ACLs and then combining them back together and could end up putting them back together in an invalid order, leading to dumps which wouldn't restore. Fix this by adjusting the queries used by pg_dump to ensure that the ACLs are rebuilt in the same order in which they were originally. Back-patch to 9.6 where the changes for initial privileges were done. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d2e40b310aea1050fd499f62f391329f2c331f6a Modified Files -- src/bin/pg_dump/dumputils.c | 51 - src/include/utils/acl.h | 14 ++--- 2 files changed, 47 insertions(+), 18 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix ordering in pg_dump of GRANTs
Fix ordering in pg_dump of GRANTs The order in which GRANTs are output is important as GRANTs which have been GRANT'd by individuals via WITH GRANT OPTION GRANTs have to come after the GRANT which included the WITH GRANT OPTION. This happens naturally in the backend during normal operation as we only change existing ACLs in-place, only add new ACLs to the end, and when removing an ACL we remove any which depend on it also. Also, adjust the comments in acl.h to make this clear. Unfortunately, the updates to pg_dump to handle initial privileges involved pulling apart ACLs and then combining them back together and could end up putting them back together in an invalid order, leading to dumps which wouldn't restore. Fix this by adjusting the queries used by pg_dump to ensure that the ACLs are rebuilt in the same order in which they were originally. Back-patch to 9.6 where the changes for initial privileges were done. Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/68a7c24fdf2d69fc57cfb26aba7e119aa6ca2621 Modified Files -- src/bin/pg_dump/dumputils.c | 51 - src/include/utils/acl.h | 14 ++--- 2 files changed, 47 insertions(+), 18 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix ordering in pg_dump of GRANTs
Fix ordering in pg_dump of GRANTs The order in which GRANTs are output is important as GRANTs which have been GRANT'd by individuals via WITH GRANT OPTION GRANTs have to come after the GRANT which included the WITH GRANT OPTION. This happens naturally in the backend during normal operation as we only change existing ACLs in-place, only add new ACLs to the end, and when removing an ACL we remove any which depend on it also. Also, adjust the comments in acl.h to make this clear. Unfortunately, the updates to pg_dump to handle initial privileges involved pulling apart ACLs and then combining them back together and could end up putting them back together in an invalid order, leading to dumps which wouldn't restore. Fix this by adjusting the queries used by pg_dump to ensure that the ACLs are rebuilt in the same order in which they were originally. Back-patch to 9.6 where the changes for initial privileges were done. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/caae416aac83db7c96695c1927a254e82f7da5dc Modified Files -- src/bin/pg_dump/dumputils.c | 51 - src/include/utils/acl.h | 14 ++--- 2 files changed, 47 insertions(+), 18 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: psql: Fix \gx when FETCH_COUNT is used
psql: Fix \gx when FETCH_COUNT is used Set expanded output when requested through \gx in ExecQueryUsingCursor() (used when FETCH_COUNT is set). Discussion: https://www.postgresql.org/message-id/CB7A53AA-5645-4BDD-AB07-4D22CD9D8FF1%40gmx.net Author: Tobias Bussmann Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/51d0fa8ed93fe5befe91498f1a3eb5aede32677a Modified Files -- src/bin/psql/common.c | 4 src/test/regress/expected/psql.out | 25 + src/test/regress/sql/psql.sql | 10 ++ 3 files changed, 39 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: psql: Fix \gx when FETCH_COUNT is used
psql: Fix \gx when FETCH_COUNT is used Set expanded output when requested through \gx in ExecQueryUsingCursor() (used when FETCH_COUNT is set). Discussion: https://www.postgresql.org/message-id/CB7A53AA-5645-4BDD-AB07-4D22CD9D8FF1%40gmx.net Author: Tobias Bussmann Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0cdc3e47bea442643c9870dc419364b9f2f52dcb Modified Files -- src/bin/psql/common.c | 4 src/test/regress/expected/psql.out | 25 + src/test/regress/sql/psql.sql | 10 ++ 3 files changed, 39 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix function comment for dumpACL()
Fix function comment for dumpACL() The comment for dumpACL() got neglected when initacls and initracls were added and the discussion of what 'racls' is wasn't very clear either. Per complaint from Tom. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/d2a51e3efcbab5b288bbadba1a7dfa123a50ba5b Modified Files -- src/bin/pg_dump/pg_dump.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix function comment for dumpACL()
Fix function comment for dumpACL() The comment for dumpACL() got neglected when initacls and initracls were added and the discussion of what 'racls' is wasn't very clear either. Per complaint from Tom. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d38e706ff149eb0937502cc0be27645e70bbfec6 Modified Files -- src/bin/pg_dump/pg_dump.c | 18 ++ 1 file changed, 14 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Do not require 'public' to exist for pg_dump -c
Do not require 'public' to exist for pg_dump -c Commit 330b84d8c4 didn't contemplate the case where the public schema has been dropped and introduced a query which fails when there is no public schema into pg_dump (when used with -c). Adjust the query used by pg_dump to handle the case where the public schema doesn't exist and add tests to check that such a case no longer fails. Back-patch the specific fix to 9.6, as the prior commit was. Adding tests for this case involved adding support to the pg_dump TAP tests to work with multiple databases, which, while not a large change, is a bit much to back-patch, so that's only done in master. Addresses bug #14650 Discussion: https://www.postgresql.org/message-id/20170512181801.1795.47483%40wrigleys.postgresql.org Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/4500edc7e9cf771bf8960d1f3f620917871bdb6f Modified Files -- src/bin/pg_dump/pg_dump.c| 7 ++- src/bin/pg_dump/t/002_pg_dump.pl | 110 +-- 2 files changed, 113 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Do not require 'public' to exist for pg_dump -c
Do not require 'public' to exist for pg_dump -c Commit 330b84d8c4 didn't contemplate the case where the public schema has been dropped and introduced a query which fails when there is no public schema into pg_dump (when used with -c). Adjust the query used by pg_dump to handle the case where the public schema doesn't exist and add tests to check that such a case no longer fails. Back-patch the specific fix to 9.6, as the prior commit was. Adding tests for this case involved adding support to the pg_dump TAP tests to work with multiple databases, which, while not a large change, is a bit much to back-patch, so that's only done in master. Addresses bug #14650 Discussion: https://www.postgresql.org/message-id/20170512181801.1795.47483%40wrigleys.postgresql.org Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a2de017b30157c99e33cbc6457140e062a5ca26f Modified Files -- src/bin/pg_dump/pg_dump.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Don't leak memory in buildDefaultACLCommands()
pg_dump: Don't leak memory in buildDefaultACLCommands() buildDefaultACLCommands() didn't destroy the string buffer created in certain cases, leading to a memory leak. Fix by destroying the buffer before returning from the function. Spotted by Coverity. Author: Michael Paquier Back-patch to 9.6 where buildDefaultACLCommands() was added. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/ef42c1103708cbbb77fff674f339d452a13aac14 Modified Files -- src/bin/pg_dump/dumputils.c | 6 ++ 1 file changed, 6 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Don't leak memory in buildDefaultACLCommands()
pg_dump: Don't leak memory in buildDefaultACLCommands() buildDefaultACLCommands() didn't destroy the string buffer created in certain cases, leading to a memory leak. Fix by destroying the buffer before returning from the function. Spotted by Coverity. Author: Michael Paquier Back-patch to 9.6 where buildDefaultACLCommands() was added. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/09f842181943b6e83b0779f2e872ff0180b66883 Modified Files -- src/bin/pg_dump/dumputils.c | 6 ++ 1 file changed, 6 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: RLS: Fix ALL vs. SELECT+UPDATE policy usage
RLS: Fix ALL vs. SELECT+UPDATE policy usage When we add the SELECT-privilege based policies to the RLS with check options (such as for an UPDATE statement, or when we have INSERT ... RETURNING), we need to be sure and use the 'USING' case if the policy is actually an 'ALL' policy (which could have both a USING clause and an independent WITH CHECK clause). This could result in policies acting differently when built using ALL (when the ALL had both USING and WITH CHECK clauses) and when building the policies independently as SELECT and UPDATE policies. Fix this by adding an explicit boolean to add_with_check_options() to indicate when the USING policy should be used, even if the policy has both USING and WITH CHECK policies on it. Reported by: Rod Taylor Back-patch to 9.5 where RLS was introduced. Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/92b15224b4eac8eeae0616491ccf0c852fa2dff9 Modified Files -- src/backend/rewrite/rowsecurity.c | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: RLS: Fix ALL vs. SELECT+UPDATE policy usage
RLS: Fix ALL vs. SELECT+UPDATE policy usage When we add the SELECT-privilege based policies to the RLS with check options (such as for an UPDATE statement, or when we have INSERT ... RETURNING), we need to be sure and use the 'USING' case if the policy is actually an 'ALL' policy (which could have both a USING clause and an independent WITH CHECK clause). This could result in policies acting differently when built using ALL (when the ALL had both USING and WITH CHECK clauses) and when building the policies independently as SELECT and UPDATE policies. Fix this by adding an explicit boolean to add_with_check_options() to indicate when the USING policy should be used, even if the policy has both USING and WITH CHECK policies on it. Reported by: Rod Taylor Back-patch to 9.5 where RLS was introduced. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/aa5d3c0b3fb906dfa910b0ca6f75ab701b2f1c09 Modified Files -- src/backend/rewrite/rowsecurity.c | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: RLS: Fix ALL vs. SELECT+UPDATE policy usage
RLS: Fix ALL vs. SELECT+UPDATE policy usage When we add the SELECT-privilege based policies to the RLS with check options (such as for an UPDATE statement, or when we have INSERT ... RETURNING), we need to be sure and use the 'USING' case if the policy is actually an 'ALL' policy (which could have both a USING clause and an independent WITH CHECK clause). This could result in policies acting differently when built using ALL (when the ALL had both USING and WITH CHECK clauses) and when building the policies independently as SELECT and UPDATE policies. Fix this by adding an explicit boolean to add_with_check_options() to indicate when the USING policy should be used, even if the policy has both USING and WITH CHECK policies on it. Reported by: Rod Taylor Back-patch to 9.5 where RLS was introduced. Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/d617c7629c0806a24c0fe74331935c726569 Modified Files -- src/backend/rewrite/rowsecurity.c | 23 +++ 1 file changed, 15 insertions(+), 8 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Change the way pg_dump retrieves partitioning info
Change the way pg_dump retrieves partitioning info This gets rid of the code that issued separate queries to retrieve the partitioning parent-child relationship, parent partition key, and child partition bound information. With this patch, the information is retrieved instead using the queries issued from getTables() and getInherits(), which is both more efficient than the previous approach and doesn't require any new code. Since the partitioning parent-child relationship is now retrieved with the same old code that handles inheritance, partition attributes receive a proper flagInhAttrs() treatment (that it didn't receive before), which is needed so that the inherited NOT NULL constraints are not emitted if we already emitted it for the parent. Also, fix a bug in pg_dump's --binary-upgrade code, which caused pg_dump to emit invalid command to attach a partition to its parent. Author: Amit Langote, with some additional changes by me. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/44c528810a1eca52a7888ed74c08353d45331b00 Modified Files -- src/bin/pg_dump/common.c | 90 - src/bin/pg_dump/pg_dump.c| 264 +-- src/bin/pg_dump/pg_dump.h| 15 +-- src/bin/pg_dump/t/002_pg_dump.pl | 36 +- 4 files changed, 153 insertions(+), 252 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Remove unnecessairly duplicated gram.y productions
Remove unnecessairly duplicated gram.y productions Declarative partitioning duplicated the TypedTableElement productions, evidently to remove the need to specify WITH OPTIONS when creating partitions. Instead, simply make WITH OPTIONS optional in the TypedTableElement production and remove all of the duplicate PartitionElement-related productions. This change simplifies the syntax and makes WITH OPTIONS optional when adding defaults, constraints or storage parameters to columns when creating either typed tables or partitions. Also update pg_dump to no longer include WITH OPTIONS, since it's not necessary, and update the documentation to reflect that WITH OPTIONS is now optional. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/b9a3ef55b253d885081c2d0e9dc45802cab71c7b Modified Files -- doc/src/sgml/ref/create_foreign_table.sgml | 2 +- doc/src/sgml/ref/create_table.sgml | 4 +- src/backend/parser/gram.y | 68 ++ src/bin/pg_dump/pg_dump.c | 17 +--- src/test/regress/expected/create_table.out | 2 +- src/test/regress/expected/sanity_check.out | 3 ++ src/test/regress/expected/typed_table.out | 37 ++-- src/test/regress/sql/create_table.sql | 2 +- src/test/regress/sql/typed_table.sql | 21 - 9 files changed, 94 insertions(+), 62 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_get_partkeydef: return NULL for non-partitions
pg_get_partkeydef: return NULL for non-partitions Our general rule for pg_get_X(oid) functions is to simply return NULL when passed an invalid or inappropriate OID. Teach pg_get_partkeydef to do this also, making it easier for users to use this function when querying against tables with both partitions and non-partitions (such as pg_class). As a concrete example, this makes pg_dump's life a little easier. Author: Amit Langote Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/0c76c2463e8ab4cfd633ad8de259050e3f28b78f Modified Files -- src/backend/utils/adt/ruleutils.c | 20 ++-- src/test/regress/expected/rules.out | 6 ++ src/test/regress/sql/rules.sql | 1 + 3 files changed, 21 insertions(+), 6 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Allow ALTER TABLE ONLY on partitioned tables
Allow ALTER TABLE ONLY on partitioned tables There is no need to forbid ALTER TABLE ONLY on partitioned tables, when no partitions exist yet. This can be handy for users who are building up their partitioned table independently and will create actual partitions later. In addition, this is how pg_dump likes to operate in certain instances. Author: Amit Langote, with some error message word-smithing by me Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/9139aa19423b736470f669e566f8ef6a7f19b801 Modified Files -- doc/src/sgml/ddl.sgml | 18 ++--- src/backend/commands/tablecmds.c | 66 +++ src/test/regress/expected/alter_table.out | 36 +++-- src/test/regress/expected/truncate.out| 8 src/test/regress/sql/alter_table.sql | 24 --- src/test/regress/sql/truncate.sql | 4 ++ 6 files changed, 108 insertions(+), 48 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Remove --verbose from PROVE_FLAGS
Remove --verbose from PROVE_FLAGS Per discussion, the TAP tests are really more verbose than necessary, so remove the --verbose flag from PROVE_FLAGS. Also add comments to let folks know how they can enable it if they really wish to, as suggested by Craig Ringer. Author: Michael Paquier, additional comments by me. Discussion: https://postgr.es/m/CAMsr%2BYGAzcMDOZ_BirnMCL6Sb%3DMUjP0FRE82YBDSbXcf6pm9Yg%40mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/e9c81b6016f431af808e4c08191e7aecf034dc80 Modified Files -- src/Makefile.global.in | 3 ++- src/test/perl/README | 5 + 2 files changed, 7 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Add COMMENT and SECURITY LABEL support for publications and subs
Peter, * Peter Eisentraut (pete...@gmx.net) wrote: > Add COMMENT and SECURITY LABEL support for publications and subscriptions Isn't this missing psql tab completion, and pg_dump support? And regression tests for the latter? Thanks! Stephen signature.asc Description: Digital signature
Re: [COMMITTERS] pgsql: Logical replication support for initial data copy
Petr, * Petr Jelinek (petr.jeli...@2ndquadrant.com) wrote: > On 23/03/17 14:47, Petr Jelinek wrote: > > I am looking into buildfarm failures. > > > > Looks like the clang issue (mylodon, longfin) is because we are missing > > extern in include/replication/worker_internal.h for ApplyCacheContext. > > > > Still analyzing the rest. > > Ah missing fields in copy/equal function for AlterSubscriptionStmt. > > Attached patch adds the above mentioned extern and fixes the copy and > equal functions. Pretty sure I saw a complaint about a trailing comma in a struct or enum too.. Thanks! Stephen signature.asc Description: Digital signature
[COMMITTERS] pgsql: Expose waitforarchive option through pg_stop_backup()
Expose waitforarchive option through pg_stop_backup() Internally, we have supported the option to either wait for all of the WAL associated with a backup to be archived, or to return immediately. This option is useful to users of pg_stop_backup() as well, when they are reading the stop backup record position and checking that the WAL they need has been archived independently. This patch adds an additional, optional, argument to pg_stop_backup() which allows the user to indicate if they wish to wait for the WAL to be archived or not. The default matches current behavior, which is to wait. Author: David Steele, with some minor changes, doc updates by me. Reviewed by: Takayuki Tsunakawa, Fujii Masao Discussion: https://postgr.es/m/758e3fd1-45b4-5e28-75cd-e9e7f93a4...@pgmasters.net Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/017e4f2588a7fc6f2d1fbb6fff8afa1ff6e31f2b Modified Files -- doc/src/sgml/backup.sgml | 13 - doc/src/sgml/func.sgml | 10 -- src/backend/access/transam/xlog.c | 3 ++- src/backend/access/transam/xlogfuncs.c | 12 ++-- src/backend/catalog/system_views.sql | 8 +++- src/include/catalog/catversion.h | 2 +- src/include/catalog/pg_proc.h | 2 +- 7 files changed, 41 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Skip COLLATION-related regression tests
pg_dump: Skip COLLATION-related regression tests Not every platform supports non-default collations, as pointed out by the buildfarm, so skip collation-related regression tests in pg_dump when they aren't supported. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/de34123834c3fa465b97f65ded171888edbfbccf Modified Files -- src/bin/pg_dump/t/002_pg_dump.pl | 29 + 1 file changed, 29 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Adjust number of tests for pg_dump 001_basic.pl
Adjust number of tests for pg_dump 001_basic.pl When removing a test, need to make sure the count of tests is adjusted when it isn't calculated. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/805e8bc7029b6eb19f0ca3a68051cfda5bd07ef3 Modified Files -- src/bin/pg_dump/t/001_basic.pl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Remove "option requires an argument -- j" test
pg_dump: Remove "option requires an argument -- j" test This is really testing getopt more than pg_dump, and what getopt returns exactly appears to differ based on platform, so remove this test. Per buildfarm. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/5abda5a3e9e7f2a472ccbb1b8389d9166d4a9eca Modified Files -- src/bin/pg_dump/t/001_basic.pl | 5 - 1 file changed, 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve pg_dump regression tests and code coverage
Improve pg_dump regression tests and code coverage These improvements bring the lines-of-code coverage of pg_dump.c up to 87.7% (at least using LCOV 1.12, 1.11 seems to differ slightly). Nearly every function is covered, three of the four which aren't are only called when talking to older PG instances. There is more which can, and should, be done here to improve the coverage but it's past time to see what the buildfarm thinks of this. What has been added: - Coverage for many more command-line options - Use command_fails_like instead of command_exit_is - Operator classes, operator families - Text search configuration, templates, parsers, dictionaries - FDWs, servers, foreign tables - Materialized views - Improved Publications / Subscriptions test (though this needs work, see PG10 open items and tests marked with XXX in 002_pg_dump.pl) - Unlogged tables - Partitioned tables - Additional ACL testing for various object types There is room for improvement, specifically: - Various type-based option (alignment, storage, etc) - Composite type collation - Extra Procedural language functions (inline, validator) - Different function options (SRF, Transform, config, security definer, cost, leakproof) - OpClass options (default, storage, order by, recheck) - OpFamily options (order by, recheck) - Aggregate functions (combinefunc, serialfunc, deserialfunc, etc) - Text Search parser 'headline' - Text Search template 'init' - FDW options (handler, validator, options) - Server options (type, version, options) - User mapping options - Default ACLs for sequences, types - Security labels - View circular dependencies (last function that needs coverage) - Toast table autovacuum options - Replica identity options - Independent indexes (plus marking them as clustered on) - Deferrable / initially deferred constraints - Independent domain constraints There's bits of extension pg_dump'ing also not covered, but those will need to go into test_pg_dump (such as having a filter for config tables). Last, but not least, this approximately halves the number of tests run with 'ok()' by removing the ok()-based checking of if all runs are covered by each test. Instead, 002_pg_dump.pl will just exit out in such a case (with a message in the log file). In general, when adding tests, cover all runs unless there is a very good reason not to (such as adding a 'catch-all' case). With these changes, the resulting output and number of "tests" run is actually reduced. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/31a8b77a9244a0883e1968adcff9b6038e575d77 Modified Files -- src/bin/pg_dump/t/001_basic.pl | 128 +- src/bin/pg_dump/t/002_pg_dump.pl | 3773 -- 2 files changed, 3340 insertions(+), 561 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Be more careful about signed vs. unsigned char
Be more careful about signed vs. unsigned char The buildfarm has reminded me that not all systems consider char to be signed and we need to be explicit. Adjust the various bits of mac8.c for what we intend, mostly using casts to unsigned char as suggested by Tom, and adjust the tests for valid input accordingly. Explicitly make the hexlookup table signed as it's useful to use -1 there to indicate an invalid value. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cccbddeb1483b85f1853a29dc3b6464647b91eee Modified Files -- src/backend/utils/adt/mac8.c | 28 ++-- 1 file changed, 14 insertions(+), 14 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Clean up overly paranoid checks in mac8.c
* Tom Lane (t...@sss.pgh.pa.us) wrote: > I wrote: > > Stephen Frost writes: > >> Clean up overly paranoid checks in mac8.c > > > termite thinks this wasn't quite right. > > On looking at it a bit more closely, I think you've forgotten that > "char" is signed on some platforms and unsigned on others. I'd > suggest putting explicit casts to unsigned char into these tests. Right, going through it now and adjusting things to be more careful about that. Thanks! Stephen signature.asc Description: Digital signature
Re: [COMMITTERS] pgsql: Clean up overly paranoid checks in mac8.c
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Clean up overly paranoid checks in mac8.c > > termite thinks this wasn't quite right. Seems to be that termite's char is unsigned, will be fixing in a moment. Thanks! Stephen signature.asc Description: Digital signature
[COMMITTERS] pgsql: Clean up overly paranoid checks in mac8.c
Clean up overly paranoid checks in mac8.c Andres' compiler points out, quite correctly, that there's no need for some of the overly paranoid checks which were put into mac8.c. Remove those, as they're useless, add some comments and make a few other minor improvements- reduce the size of hexlookup by making it a char array instead of an int array, and pass in the ptr location directly instead of making hex2_to_uchar re-calculate the location based off the offset every time. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/7821f7229c6e149046ee0dd8cab57928c4f86a37 Modified Files -- src/backend/utils/adt/mac8.c | 42 +- 1 file changed, 25 insertions(+), 17 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Bump catversion for MACADDR8
Bump catversion for MACADDR8 Pointed out by Robert. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/c5832346625af4193b1242e57e7d13e66a220b38 Modified Files -- src/include/catalog/catversion.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Add support for EUI-64 MAC addresses as macaddr8
Add support for EUI-64 MAC addresses as macaddr8 This adds in support for EUI-64 MAC addresses by adding a new data type called 'macaddr8' (using our usual convention of indicating the number of bytes stored). This was largely a copy-and-paste from the macaddr data type, with appropriate adjustments for having 8 bytes instead of 6 and adding support for converting a provided EUI-48 (6 byte format) to the EUI-64 format. Conversion from EUI-48 to EUI-64 inserts FFFE as the 4th and 5th bytes but does not perform the IPv6 modified EUI-64 action of flipping the 7th bit, but we add a function to perform that specific action for the user as it may be commonly done by users who wish to calculate their IPv6 address based on their network prefix and 48-bit MAC address. Author: Haribabu Kommi, with a good bit of rework of macaddr8_in by me. Reviewed by: Vitaly Burovoy, Kuntal Ghosh Discussion: https://postgr.es/m/CAJrrPGcUi8ZH+KkK+=tctnq+efkecehtmu_yo1mvx8hsk_g...@mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/c7a9fa399d557c6366222e90b35db31e45d25678 Modified Files -- contrib/btree_gin/Makefile | 4 +- contrib/btree_gin/btree_gin--1.0--1.1.sql | 35 ++ contrib/btree_gin/btree_gin.c | 10 + contrib/btree_gin/btree_gin.control | 2 +- contrib/btree_gin/expected/macaddr8.out | 51 +++ contrib/btree_gin/sql/macaddr8.sql | 22 ++ contrib/btree_gist/Makefile | 11 +- contrib/btree_gist/btree_gist--1.3--1.4.sql | 64 contrib/btree_gist/btree_gist.control | 2 +- contrib/btree_gist/btree_gist.h | 1 + contrib/btree_gist/btree_macaddr8.c | 200 ++ contrib/btree_gist/expected/macaddr8.out| 89 + contrib/btree_gist/sql/macaddr8.sql | 37 ++ doc/src/sgml/brin.sgml | 11 + doc/src/sgml/btree-gin.sgml | 3 +- doc/src/sgml/btree-gist.sgml| 4 +- doc/src/sgml/datatype.sgml | 83 + doc/src/sgml/func.sgml | 56 +++ src/backend/utils/adt/Makefile | 2 +- src/backend/utils/adt/mac.c | 13 +- src/backend/utils/adt/mac8.c| 560 src/backend/utils/adt/network.c | 10 + src/backend/utils/adt/selfuncs.c| 1 + src/include/catalog/pg_amop.h | 18 + src/include/catalog/pg_amproc.h | 7 + src/include/catalog/pg_cast.h | 6 + src/include/catalog/pg_opclass.h| 3 + src/include/catalog/pg_operator.h | 23 +- src/include/catalog/pg_opfamily.h | 3 + src/include/catalog/pg_proc.h | 37 +- src/include/catalog/pg_type.h | 4 + src/include/utils/inet.h| 22 ++ src/test/regress/expected/macaddr8.out | 354 ++ src/test/regress/expected/opr_sanity.out| 6 + src/test/regress/parallel_schedule | 2 +- src/test/regress/serial_schedule| 1 + src/test/regress/sql/macaddr8.sql | 89 + 37 files changed, 1826 insertions(+), 20 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pgstattuple: Fix typo partitiond -> partitioned
pgstattuple: Fix typo partitiond -> partitioned Pointed out by Michael Paquier Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/90e91e242fe99582b6d2dc18177e79d99c91695d Modified Files -- contrib/pgstattuple/expected/pgstattuple.out | 2 +- contrib/pgstattuple/sql/pgstattuple.sql | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Add relkind checks to certain contrib modules
Add relkind checks to certain contrib modules The contrib extensions pageinspect, pg_visibility and pgstattuple only work against regular relations which have storage. They don't work against foreign tables, partitioned (parent) tables, views, et al. Add checks to the user-callable functions to return a useful error message to the user if they mistakenly pass an invalid relation to a function which doesn't accept that kind of relation. In passing, improve some of the existing checks to use ereport() instead of elog(), add a function to consolidate common checks where appropriate, and add some regression tests. Author: Amit Langote, with various changes by me Reviewed by: Michael Paquier and Corey Huinker Discussion: https://postgr.es/m/ab91fd9d-4751-ee77-c87b-4dd704c1e...@lab.ntt.co.jp Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/c08d82f38ebf763b79bd43ae34b7310ee47aaacd Modified Files -- contrib/pageinspect/expected/page.out| 9 ++ contrib/pageinspect/rawpage.c| 5 + contrib/pageinspect/sql/page.sql | 9 ++ contrib/pg_visibility/.gitignore | 4 + contrib/pg_visibility/Makefile | 2 + contrib/pg_visibility/expected/pg_visibility.out | 142 +++ contrib/pg_visibility/pg_visibility.c| 58 ++--- contrib/pg_visibility/sql/pg_visibility.sql | 83 + contrib/pgstattuple/expected/pgstattuple.out | 107 + contrib/pgstattuple/pgstatindex.c| 52 +++-- contrib/pgstattuple/pgstattuple.c| 3 + contrib/pgstattuple/sql/pgstattuple.sql | 64 ++ 12 files changed, 517 insertions(+), 21 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Expose explain's SUMMARY option
Expose explain's SUMMARY option This exposes the existing explain summary option to users to allow them to choose if they wish to have the planning time and totalled run time included in the EXPLAIN result. The existing default behavior is retained if SUMMARY is not specified- running explain without analyze will not print the summary lines (just the planning time, currently) while running explain with analyze will include the summary lines (both the planning time and the totalled execution time). Users who wish to see the summary information for plain explain can now use: EXPLAIN (SUMMARY ON) query; Users who do not want to have the summary printed for an analyze run can use: EXPLAIN (ANALYZE ON, SUMMARY OFF) query; With this, we can now also have EXPLAIN ANALYZE queries included in our regression tests by using: EXPLAIN (ANALYZE ON, TIMING OFF, SUMMARY off) query; I went ahead and added an example of this, which will hopefully not make the buildfarm complain. Author: Ashutosh Bapat Discussion: https://postgr.es/m/cafjfpree5z2h98u2vuia8hcekprrwraurjhmye44hnv8-xk...@mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/f9b1a0dd403ec0931213c66d5f979a3d3e8e7e30 Modified Files -- doc/src/sgml/ref/explain.sgml| 16 src/backend/commands/explain.c | 18 +++--- src/backend/commands/prepare.c | 9 - src/test/regress/expected/select.out | 10 ++ src/test/regress/sql/select.sql | 3 +++ 5 files changed, 52 insertions(+), 4 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: psql: Add \gx command
psql: Add \gx command It can often be useful to use expanded mode output (\x) for just a single query. Introduce a \gx which acts exactly like \g except that it will force expanded output mode for that one \gx call. This is simpler than having to use \x as a toggle and also means that the user doesn't have to worry about the current state of the expanded variable, or resetting it later, to ensure a given query is always returned in expanded mode. Primairly Christoph's patch, though I did tweak the documentation and help text a bit, and re-indented the tab completion section. Author: Christoph Berg Reviewed By: Daniel Verite Discussion: https://postgr.es/m/20170127132737.6skslelaf4txs6iw%40msg.credativ.de Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/b2678efd43f17db7dfa04e0ca076ea01275cd9bc Modified Files -- doc/src/sgml/ref/psql-ref.sgml | 12 src/bin/psql/command.c | 9 +++-- src/bin/psql/common.c | 7 +++ src/bin/psql/help.c| 1 + src/bin/psql/settings.h| 1 + src/bin/psql/tab-complete.c| 11 ++- src/test/regress/expected/psql.out | 23 +++ src/test/regress/sql/psql.sql | 7 +++ 8 files changed, 64 insertions(+), 7 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Properly handle public schema ACLs with --clean
pg_dump: Properly handle public schema ACLs with --clean pg_dump has always handled the public schema in a special way when it comes to the "--clean" option. To wit, we do not drop or recreate the public schema in "normal" mode, but when we are run in "--clean" mode then we do drop and recreate the public schema. When running in "--clean" mode, the public schema is dropped and then recreated and it is recreated with the normal schema-default privileges of "nothing". This is unlike how the public schema starts life, which is to have CREATE and USAGE GRANT'd to the PUBLIC role, and that is what is recorded in pg_init_privs. Due to this, in "--clean" mode, pg_dump would mistakenly only dump out the set of privileges required to go from the initdb-time privileges on the public schema to whatever the current-state privileges are. If the privileges were not changed from initdb time, then no privileges would be dumped out for the public schema, but with the schema being dropped and recreated, the result was that the public schema would have no ACLs on it instead of what it should have, which is the initdb-time privileges. Practically speaking, this meant that pg_dump with --clean mode dumping a database where the ACLs on the public schema were not changed from the default would, upon restore, result in a public schema with *no* privileges GRANT'd, not matching the state of the existing database (where the initdb-time privileges would have been CREATE and USAGE to the PUBLIC role for the public schema). To fix, adjust the query in getNamespaces() to ignore the pg_init_privs entry for the public schema when running in "--clean" mode, meaning that the privileges for the public schema would be dumped, correctly, as if it was going from a newly-created schema to the current state (which is, indeed, what will happen during the restore thanks to the DROP/CREATE). Only the public schema is handled in this special way by pg_dump, no other initdb-time objects are dropped/recreated in --clean mode. Back-patch to 9.6 where the bug was introduced. Discussion: https://postgr.es/m/3534542.o3cNaKiDID%40techfox Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/e961341cc1491ddf41e9408d9b1d3342df9ea2c2 Modified Files -- src/bin/pg_dump/pg_dump.c| 22 +- src/bin/pg_dump/t/002_pg_dump.pl | 26 -- 2 files changed, 45 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Properly handle public schema ACLs with --clean
pg_dump: Properly handle public schema ACLs with --clean pg_dump has always handled the public schema in a special way when it comes to the "--clean" option. To wit, we do not drop or recreate the public schema in "normal" mode, but when we are run in "--clean" mode then we do drop and recreate the public schema. When running in "--clean" mode, the public schema is dropped and then recreated and it is recreated with the normal schema-default privileges of "nothing". This is unlike how the public schema starts life, which is to have CREATE and USAGE GRANT'd to the PUBLIC role, and that is what is recorded in pg_init_privs. Due to this, in "--clean" mode, pg_dump would mistakenly only dump out the set of privileges required to go from the initdb-time privileges on the public schema to whatever the current-state privileges are. If the privileges were not changed from initdb time, then no privileges would be dumped out for the public schema, but with the schema being dropped and recreated, the result was that the public schema would have no ACLs on it instead of what it should have, which is the initdb-time privileges. Practically speaking, this meant that pg_dump with --clean mode dumping a database where the ACLs on the public schema were not changed from the default would, upon restore, result in a public schema with *no* privileges GRANT'd, not matching the state of the existing database (where the initdb-time privileges would have been CREATE and USAGE to the PUBLIC role for the public schema). To fix, adjust the query in getNamespaces() to ignore the pg_init_privs entry for the public schema when running in "--clean" mode, meaning that the privileges for the public schema would be dumped, correctly, as if it was going from a newly-created schema to the current state (which is, indeed, what will happen during the restore thanks to the DROP/CREATE). Only the public schema is handled in this special way by pg_dump, no other initdb-time objects are dropped/recreated in --clean mode. Back-patch to 9.6 where the bug was introduced. Discussion: https://postgr.es/m/3534542.o3cNaKiDID%40techfox Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/330b84d8c40864007833e05dc9d849c4bda77240 Modified Files -- src/bin/pg_dump/pg_dump.c| 22 +- src/bin/pg_dump/t/002_pg_dump.pl | 32 ++-- 2 files changed, 51 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the information which can be associated with large objects. Currently, we also support COMMENTs and SECURITY LABELs with large objects and these were being silently dropped during a pg_upgrade as pg_dump would skip everything having to do with a large object and pg_upgrade only copied the tables mentioned to the new cluster. As the file copies happen after the catalog dump and reload, we can't simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode output but we also have to include the actual large object definition as well. With the definition, comments, and security labels in the pg_dump output and the file copies performed by pg_upgrade, all of the data and metadata associated with large objects is able to be successfully pulled forward across a pg_upgrade. In 9.6 and master, we can simply adjust the dump bitmask to indicate which components we don't want. In 9.5 and earlier, we have to put explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL or the data when in binary-upgrade mode. Adjustments made to the privileges regression test to allow another test (large_object.sql) to be added which explicitly leaves a large object with a comment in place to provide coverage of that case with pg_upgrade. Back-patch to all supported branches. Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/6be8647f7862dbbefe4d49d842566738cd753963 Modified Files -- src/bin/pg_dump/pg_backup.h| 1 + src/bin/pg_dump/pg_backup_archiver.c | 12 ++- src/bin/pg_dump/pg_dump.c | 34 +- src/test/regress/expected/large_object.out | 15 + src/test/regress/expected/privileges.out | 8 +++ src/test/regress/parallel_schedule | 2 +- src/test/regress/serial_schedule | 1 + src/test/regress/sql/large_object.sql | 7 ++ src/test/regress/sql/privileges.sql| 6 +++--- 9 files changed, 72 insertions(+), 14 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the information which can be associated with large objects. Currently, we also support COMMENTs and SECURITY LABELs with large objects and these were being silently dropped during a pg_upgrade as pg_dump would skip everything having to do with a large object and pg_upgrade only copied the tables mentioned to the new cluster. As the file copies happen after the catalog dump and reload, we can't simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode output but we also have to include the actual large object definition as well. With the definition, comments, and security labels in the pg_dump output and the file copies performed by pg_upgrade, all of the data and metadata associated with large objects is able to be successfully pulled forward across a pg_upgrade. In 9.6 and master, we can simply adjust the dump bitmask to indicate which components we don't want. In 9.5 and earlier, we have to put explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL or the data when in binary-upgrade mode. Adjustments made to the privileges regression test to allow another test (large_object.sql) to be added which explicitly leaves a large object with a comment in place to provide coverage of that case with pg_upgrade. Back-patch to all supported branches. Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/93598898c8d203ef296f4f5870c5f948e9fda416 Modified Files -- src/bin/pg_dump/pg_backup.h| 1 + src/bin/pg_dump/pg_backup_archiver.c | 12 ++- src/bin/pg_dump/pg_dump.c | 34 +- src/test/regress/expected/large_object.out | 15 + src/test/regress/expected/privileges.out | 8 +++ src/test/regress/parallel_schedule | 2 +- src/test/regress/serial_schedule | 1 + src/test/regress/sql/large_object.sql | 7 ++ src/test/regress/sql/privileges.sql| 6 +++--- 9 files changed, 72 insertions(+), 14 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the information which can be associated with large objects. Currently, we also support COMMENTs and SECURITY LABELs with large objects and these were being silently dropped during a pg_upgrade as pg_dump would skip everything having to do with a large object and pg_upgrade only copied the tables mentioned to the new cluster. As the file copies happen after the catalog dump and reload, we can't simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode output but we also have to include the actual large object definition as well. With the definition, comments, and security labels in the pg_dump output and the file copies performed by pg_upgrade, all of the data and metadata associated with large objects is able to be successfully pulled forward across a pg_upgrade. In 9.6 and master, we can simply adjust the dump bitmask to indicate which components we don't want. In 9.5 and earlier, we have to put explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL or the data when in binary-upgrade mode. Adjustments made to the privileges regression test to allow another test (large_object.sql) to be added which explicitly leaves a large object with a comment in place to provide coverage of that case with pg_upgrade. Back-patch to all supported branches. Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/e864cd25b4f5a85e0c236cf845daff99433937db Modified Files -- src/bin/pg_dump/pg_backup.h| 1 + src/bin/pg_dump/pg_backup_archiver.c | 12 ++- src/bin/pg_dump/pg_dump.c | 34 +- src/test/regress/expected/large_object.out | 15 + src/test/regress/expected/privileges.out | 8 +++ src/test/regress/parallel_schedule | 2 +- src/test/regress/serial_schedule | 1 + src/test/regress/sql/large_object.sql | 7 ++ src/test/regress/sql/privileges.sql| 6 +++--- 9 files changed, 72 insertions(+), 14 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the information which can be associated with large objects. Currently, we also support COMMENTs and SECURITY LABELs with large objects and these were being silently dropped during a pg_upgrade as pg_dump would skip everything having to do with a large object and pg_upgrade only copied the tables mentioned to the new cluster. As the file copies happen after the catalog dump and reload, we can't simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode output but we also have to include the actual large object definition as well. With the definition, comments, and security labels in the pg_dump output and the file copies performed by pg_upgrade, all of the data and metadata associated with large objects is able to be successfully pulled forward across a pg_upgrade. In 9.6 and master, we can simply adjust the dump bitmask to indicate which components we don't want. In 9.5 and earlier, we have to put explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL or the data when in binary-upgrade mode. Adjustments made to the privileges regression test to allow another test (large_object.sql) to be added which explicitly leaves a large object with a comment in place to provide coverage of that case with pg_upgrade. Back-patch to all supported branches. Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/65a3f233b2cf9aa7750d0c634654a65f4c5579c4 Modified Files -- src/bin/pg_dump/pg_backup.h| 1 + src/bin/pg_dump/pg_backup_archiver.c | 12 +++- src/bin/pg_dump/pg_dump.c | 31 +++--- src/test/regress/expected/large_object.out | 15 +++ src/test/regress/expected/privileges.out | 8 src/test/regress/parallel_schedule | 2 +- src/test/regress/serial_schedule | 1 + src/test/regress/sql/large_object.sql | 8 src/test/regress/sql/privileges.sql| 6 +++--- 9 files changed, 72 insertions(+), 12 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the information which can be associated with large objects. Currently, we also support COMMENTs and SECURITY LABELs with large objects and these were being silently dropped during a pg_upgrade as pg_dump would skip everything having to do with a large object and pg_upgrade only copied the tables mentioned to the new cluster. As the file copies happen after the catalog dump and reload, we can't simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode output but we also have to include the actual large object definition as well. With the definition, comments, and security labels in the pg_dump output and the file copies performed by pg_upgrade, all of the data and metadata associated with large objects is able to be successfully pulled forward across a pg_upgrade. In 9.6 and master, we can simply adjust the dump bitmask to indicate which components we don't want. In 9.5 and earlier, we have to put explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL or the data when in binary-upgrade mode. Adjustments made to the privileges regression test to allow another test (large_object.sql) to be added which explicitly leaves a large object with a comment in place to provide coverage of that case with pg_upgrade. Back-patch to all supported branches. Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/7f831f09bb85d93d99f55269479e4b6d105937f8 Modified Files -- src/bin/pg_dump/pg_backup.h| 1 + src/bin/pg_dump/pg_backup_archiver.c | 12 ++- src/bin/pg_dump/pg_dump.c | 34 +- src/test/regress/expected/large_object.out | 15 + src/test/regress/expected/privileges.out | 8 +++ src/test/regress/parallel_schedule | 2 +- src/test/regress/serial_schedule | 1 + src/test/regress/sql/large_object.sql | 7 ++ src/test/regress/sql/privileges.sql| 6 +++--- 9 files changed, 72 insertions(+), 14 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_upgrade: Fix large object COMMENTS, SECURITY LABELS
pg_upgrade: Fix large object COMMENTS, SECURITY LABELS When performing a pg_upgrade, we copy the files behind pg_largeobject and pg_largeobject_metadata, allowing us to avoid having to dump out and reload the actual data for large objects and their ACLs. Unfortunately, that isn't all of the information which can be associated with large objects. Currently, we also support COMMENTs and SECURITY LABELs with large objects and these were being silently dropped during a pg_upgrade as pg_dump would skip everything having to do with a large object and pg_upgrade only copied the tables mentioned to the new cluster. As the file copies happen after the catalog dump and reload, we can't simply include the COMMENTs and SECURITY LABELs in pg_dump's binary-mode output but we also have to include the actual large object definition as well. With the definition, comments, and security labels in the pg_dump output and the file copies performed by pg_upgrade, all of the data and metadata associated with large objects is able to be successfully pulled forward across a pg_upgrade. In 9.6 and master, we can simply adjust the dump bitmask to indicate which components we don't want. In 9.5 and earlier, we have to put explciit checks in in dumpBlob() and dumpBlobs() to not include the ACL or the data when in binary-upgrade mode. Adjustments made to the privileges regression test to allow another test (large_object.sql) to be added which explicitly leaves a large object with a comment in place to provide coverage of that case with pg_upgrade. Back-patch to all supported branches. Discussion: https://postgr.es/m/20170221162655.ge9...@tamriel.snowman.net Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/ff992c074e308ade204a38eb43a6d19c8403414e Modified Files -- src/bin/pg_dump/pg_backup.h| 1 + src/bin/pg_dump/pg_backup_archiver.c | 10 +- src/bin/pg_dump/pg_dump.c | 31 +++--- src/bin/pg_dump/t/002_pg_dump.pl | 14 ++ src/test/regress/expected/large_object.out | 15 +++ src/test/regress/expected/privileges.out | 8 src/test/regress/parallel_schedule | 2 +- src/test/regress/serial_schedule | 1 + src/test/regress/sql/large_object.sql | 8 src/test/regress/sql/privileges.sql| 6 +++--- 10 files changed, 80 insertions(+), 16 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Mark pg_start_backup and pg_stop_backup as parallel-restricted.
Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > David Steele writes: > > On 3/6/17 12:48 PM, Robert Haas wrote: > >> This issue also exists in 9.6, but we obviously can't do anything > >> about 9.6 clusters that already exist. Possibly this could be > >> back-patched so that future 9.6 clusters would come out OK, or > >> possibly we should back-patch some other fix, but that would need more > >> discussion. > > > I think it would be worth back-patching the catalog fix for future 9.6 > > clusters as a start. > > Yes, I think it's rather silly not to do so. We have made comparable > backpatched fixes multiple times in the past. What is worth discussing is > whether there are *additional* things we ought to do in 9.6 to prevent > misbehavior in installations initdb'd pre-9.6.3. > > If there's a cheap way of testing "AmInParallelWorker", I'd be in favor of > adding a quick-n-dirty test and ereport(ERROR) to these functions in the > 9.6 branch, so that at least you get a clean error and not some weird > misbehavior. Not sure if there's anything more we can do than that. That's more-or-less what I was thinking (and suggested to David over IM a little while ago, actually). I don't know if there's an easy way to do such a check, but I don't think it would really need to be particularly cheap, just not overly complex. These code paths are certainly not ones that need to be high-performance. Thanks! Stephen signature.asc Description: Digital signature
[COMMITTERS] pgsql: Initialize number_of_jobs in NewRestoreOptions
Initialize number_of_jobs in NewRestoreOptions Now that we're checking that the number_of_jobs passed in isn't zero or negative, we need to actually initialize number_of_jobs to '1' when it isn't set. Pointed out by Rushabh Lathia, though not his patch. Discussion: https://postgr.es/m/CAGPqQf2u1T3J=anhcw1cuvzqjd80owvmg2-2wmfg08gcm9h...@mail.gmail.com Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/0021ce274319215fdc481ae29f059068f7a5bf0a Modified Files -- src/bin/pg_dump/pg_backup_archiver.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES
pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES In commit 23f34fa, we changed how ACLs were handled to use the new pg_init_privs catalog and to dump out the ACL commands as REVOKE+GRANT combinations instead of trying to REVOKE all rights always and then GRANT back just the ones which were in place. Unfortunately, the DEFAULT PRIVILEGES system didn't quite get the correct treatment with this change and ended up (incorrectly) only including positive GRANTs instead of both the REVOKEs and GRANTs necessary to preserve the correct privileges. There are only a couple cases where such REVOKEs are possible because, generally speaking, there's few rights which exist on objects by default to be revoked. Examples of REVOKEs which weren't being correctly preserved are when privileges are REVOKE'd from the creator/owner, like so: ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE SELECT ON TABLES FROM myrole; or when other default privileges are being revoked, such as EXECUTE rights granted to public for functions: ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC; Fix this by correctly working out what the correct REVOKE statements are (if any) and dump them out, just as we do for everything else. Noticed while developing additional regression tests for pg_dump, which will be landing shortly. Back-patch to 9.6 where the bug was introduced. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/e2090d9d20d8091c9478a674d9c22fc8006909ce Modified Files -- src/bin/pg_dump/dumputils.c | 23 - src/bin/pg_dump/dumputils.h | 4 ++- src/bin/pg_dump/pg_dump.c | 63 - src/bin/pg_dump/pg_dump.h | 3 +++ 4 files changed, 78 insertions(+), 15 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES
pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES In commit 23f34fa, we changed how ACLs were handled to use the new pg_init_privs catalog and to dump out the ACL commands as REVOKE+GRANT combinations instead of trying to REVOKE all rights always and then GRANT back just the ones which were in place. Unfortunately, the DEFAULT PRIVILEGES system didn't quite get the correct treatment with this change and ended up (incorrectly) only including positive GRANTs instead of both the REVOKEs and GRANTs necessary to preserve the correct privileges. There are only a couple cases where such REVOKEs are possible because, generally speaking, there's few rights which exist on objects by default to be revoked. Examples of REVOKEs which weren't being correctly preserved are when privileges are REVOKE'd from the creator/owner, like so: ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE SELECT ON TABLES FROM myrole; or when other default privileges are being revoked, such as EXECUTE rights granted to public for functions: ALTER DEFAULT PRIVILEGES FOR ROLE myrole REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC; Fix this by correctly working out what the correct REVOKE statements are (if any) and dump them out, just as we do for everything else. Noticed while developing additional regression tests for pg_dump, which will be landing shortly. Back-patch to 9.6 where the bug was introduced. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/eb5e9d90df7536d0cf5c0d669d874f91b7be36d6 Modified Files -- src/bin/pg_dump/dumputils.c | 23 - src/bin/pg_dump/dumputils.h | 4 ++- src/bin/pg_dump/pg_dump.c | 63 - src/bin/pg_dump/pg_dump.h | 3 +++ 4 files changed, 78 insertions(+), 15 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: perltidy pg_dump TAP tests
perltidy pg_dump TAP tests The pg_dump TAP tests have gotten pretty far from what perltidy thinks they should be, so fix that, and in passing use long-form argument names with arguments passed via "=" in a similar vein to 58da833. No functional changes here, just whitespace and changing runs from "-f" to "--file=", and similar. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/6af8b89adba16f97bee0d3b01256861e10d0e4f1 Modified Files -- src/bin/pg_dump/t/001_basic.pl| 14 +- src/bin/pg_dump/t/002_pg_dump.pl | 727 +- src/bin/pg_dump/t/010_dump_connstr.pl | 169 3 files changed, 477 insertions(+), 433 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: test_pg_dump: perltidy cleanup
test_pg_dump: perltidy cleanup As pointed out by Alvaro, we actually use perltidy on the perl scripts in the source tree, so go back to the results of a perltidy run for the test_pg_dump TAP script. To make it look slightly less tragic, I changed most of the independent arguments into long-form single arguments (eg: -f file.sql changed to be --file=file.sql) to avoid having them confusingly split across lines due to perltidy. Back-patch to 9.6, as the last patch was. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/58da8334308c26107ebb7ee06c99589e14bd882b Modified Files -- src/test/modules/test_pg_dump/t/001_base.pl | 885 1 file changed, 377 insertions(+), 508 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: test_pg_dump: perltidy cleanup
test_pg_dump: perltidy cleanup As pointed out by Alvaro, we actually use perltidy on the perl scripts in the source tree, so go back to the results of a perltidy run for the test_pg_dump TAP script. To make it look slightly less tragic, I changed most of the independent arguments into long-form single arguments (eg: -f file.sql changed to be --file=file.sql) to avoid having them confusingly split across lines due to perltidy. Back-patch to 9.6, as the last patch was. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/3e9c36165377b07ffb182c366e295ac48ea5d5ba Modified Files -- src/test/modules/test_pg_dump/t/001_base.pl | 885 1 file changed, 377 insertions(+), 508 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Stephen Frost wrote: > > test_pg_dump TAP test whitespace cleanup > > > > The formatting of the perl hashes used in the TAP tests for test_pg_dump > > was rather horribly inconsistent and made it more difficult than it > > really should have been to add new tests or adjust what tests are for > > what runs, etc. > > > > Reformat to clean that all up. > > > > Whitespace-only changes. > > This will be undone by the next perltidy run. Ugh. I certainly hope what was there before wasn't the result of a perltidy run as it was quite ugly and inconsistent.. Thanks! Stephen signature.asc Description: Digital signature
[COMMITTERS] pgsql: Handle ALTER EXTENSION ADD/DROP with pg_init_privs
Handle ALTER EXTENSION ADD/DROP with pg_init_privs In commit 6c268df, pg_init_privs was added to track the initial privileges of catalog objects and extensions. Unfortunately, that commit didn't include understanding of ALTER EXTENSION ADD/DROP, which allows the objects associated with an extension to be changed after the initial CREATE EXTENSION script has been run. The result of this meant that ACLs for objects added through ALTER EXTENSION ADD were not recorded into pg_init_privs and we would end up including those ACLs in pg_dump when we shouldn't have. This commit corrects that by making sure to have pg_init_privs updated when ALTER EXTENSION ADD/DROP is run, recording the permissions as they are at ALTER EXTENSION ADD time, and removing any if/when ALTER EXTENSION DROP is called. This issue was pointed out by Moshe Jacobson as commentary on bug #14456 (which was actually a bug about versions prior to 9.6 not handling custom ACLs on extensions correctly, an issue now addressed with pg_init_privs in 9.6). Back-patch to 9.6 where pg_init_privs was introduced. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/e54f75722c720b596ec5e72154cc899da199de5b Modified Files -- src/backend/catalog/aclchk.c | 436 +++-- src/backend/commands/extension.c | 21 + src/include/utils/acl.h| 4 + .../modules/test_pg_dump/expected/test_pg_dump.out | 100 - src/test/modules/test_pg_dump/sql/test_pg_dump.sql | 108 - src/test/modules/test_pg_dump/t/001_base.pl| 92 + 6 files changed, 732 insertions(+), 29 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Handle ALTER EXTENSION ADD/DROP with pg_init_privs
Handle ALTER EXTENSION ADD/DROP with pg_init_privs In commit 6c268df, pg_init_privs was added to track the initial privileges of catalog objects and extensions. Unfortunately, that commit didn't include understanding of ALTER EXTENSION ADD/DROP, which allows the objects associated with an extension to be changed after the initial CREATE EXTENSION script has been run. The result of this meant that ACLs for objects added through ALTER EXTENSION ADD were not recorded into pg_init_privs and we would end up including those ACLs in pg_dump when we shouldn't have. This commit corrects that by making sure to have pg_init_privs updated when ALTER EXTENSION ADD/DROP is run, recording the permissions as they are at ALTER EXTENSION ADD time, and removing any if/when ALTER EXTENSION DROP is called. This issue was pointed out by Moshe Jacobson as commentary on bug #14456 (which was actually a bug about versions prior to 9.6 not handling custom ACLs on extensions correctly, an issue now addressed with pg_init_privs in 9.6). Back-patch to 9.6 where pg_init_privs was introduced. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/20064c0ec201fd2302757c1fdb2279e9dc9a4030 Modified Files -- src/backend/catalog/aclchk.c | 436 +++-- src/backend/commands/extension.c | 21 + src/include/utils/acl.h| 4 + .../modules/test_pg_dump/expected/test_pg_dump.out | 100 - src/test/modules/test_pg_dump/sql/test_pg_dump.sql | 108 - src/test/modules/test_pg_dump/t/001_base.pl| 92 + 6 files changed, 732 insertions(+), 29 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup
test_pg_dump TAP test whitespace cleanup The formatting of the perl hashes used in the TAP tests for test_pg_dump was rather horribly inconsistent and made it more difficult than it really should have been to add new tests or adjust what tests are for what runs, etc. Reformat to clean that all up. Whitespace-only changes. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/73cd4896f41052bdaf779fa1b63aca5f10c56a62 Modified Files -- src/test/modules/test_pg_dump/t/001_base.pl | 784 1 file changed, 462 insertions(+), 322 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: test_pg_dump TAP test whitespace cleanup
test_pg_dump TAP test whitespace cleanup The formatting of the perl hashes used in the TAP tests for test_pg_dump was rather horribly inconsistent and made it more difficult than it really should have been to add new tests or adjust what tests are for what runs, etc. Reformat to clean that all up. Whitespace-only changes. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/fb94ca77f1400e236b00d432dccfbe4f1124971c Modified Files -- src/test/modules/test_pg_dump/t/001_base.pl | 784 1 file changed, 462 insertions(+), 322 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Logical replication
* Peter Eisentraut (pete...@gmx.net) wrote: > Logical replication > > - Add PUBLICATION catalogs and DDL > - Add SUBSCRIPTION catalog and DDL > - Define logical replication protocol and output plugin > - Add logical replication workers The buildfarm is rather upset with this. Looks like an issue in pg_upgrade / pg_dump. Thanks! Stephen signature.asc Description: Digital signature
[COMMITTERS] pgsql: Dump sequence data based on the TableDataInfo flag
Dump sequence data based on the TableDataInfo flag When considering a sequence's Data entry in dumpSequenceData, we were actually looking at the sequence definition's dump flag to decide if we should dump the data or not. That's generally fine, except for when the sequence data entry was created by processExtensionTables() because it's a config sequence. In that case, the sequence itself won't be marked as dumping data because it's part of an extension, leading to the need for processExtensionTables() to create the sequence data entry. This leads to extension config sequence data not being included in the dump when it should be. Fix this by looking at the sequence data's dump flag instead, just as dumpTableData() was doing for tables (which is why config tables were correctly being handled), and add a regression test to make sure we don't break it moving forward. All of this is a bit round-about since we can now represent which components of a given dump item should be dumped out through the dump flag. A future improvement might be to change checkExtensionMembership() to check for config sequences/tables and set the dump flag based on that directly, possibly removing the need for processExtensionTables(). Bug found by Daniele Varrazzo. Discussion: https://postgr.es/m/CA+mi_8ZmxQM7+nZ7pJ8uyfxc9V3o=uag14dvqvftdmvw8oj...@mail.gmail.com Patch by Michael Paquier, with some tweaking of the regression tests by me. Back-patch to 9.6 where the bug was introduced. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/bec96c82f8ff4fcf7ef0f070f6f7447edf106de3 Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- src/test/modules/test_pg_dump/t/001_base.pl | 19 +++ src/test/modules/test_pg_dump/test_pg_dump--1.0.sql | 3 +++ 3 files changed, 23 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Dump sequence data based on the TableDataInfo flag
Dump sequence data based on the TableDataInfo flag When considering a sequence's Data entry in dumpSequenceData, we were actually looking at the sequence definition's dump flag to decide if we should dump the data or not. That's generally fine, except for when the sequence data entry was created by processExtensionTables() because it's a config sequence. In that case, the sequence itself won't be marked as dumping data because it's part of an extension, leading to the need for processExtensionTables() to create the sequence data entry. This leads to extension config sequence data not being included in the dump when it should be. Fix this by looking at the sequence data's dump flag instead, just as dumpTableData() was doing for tables (which is why config tables were correctly being handled), and add a regression test to make sure we don't break it moving forward. All of this is a bit round-about since we can now represent which components of a given dump item should be dumped out through the dump flag. A future improvement might be to change checkExtensionMembership() to check for config sequences/tables and set the dump flag based on that directly, possibly removing the need for processExtensionTables(). Bug found by Daniele Varrazzo. Discussion: https://postgr.es/m/CA+mi_8ZmxQM7+nZ7pJ8uyfxc9V3o=uag14dvqvftdmvw8oj...@mail.gmail.com Patch by Michael Paquier, with some tweaking of the regression tests by me. Back-patch to 9.6 where the bug was introduced. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/fd081cabf7c3ce514d28e8de1a9b5c8717ea1130 Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- src/test/modules/test_pg_dump/t/001_base.pl | 19 +++ src/test/modules/test_pg_dump/test_pg_dump--1.0.sql | 3 +++ 3 files changed, 23 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Add function to import operating system collations
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > >> WFM. Btw, I noticed that BOOTSTRAP_SUPERUSERID is hard-coded as "10" > >> in this bit in setup_privileges(): > > > Hm. I seem to recall trying to avoid having the hard-coded value there > > but we don't have BOOTSTRAP_SUPERUSERID defined somewhere that initdb.c > > could include it from, do we? It's only in catalog/pg_authid.h. > > Looks to me like including catalog/pg_authid.h in initdb would work fine. > pg_upgrade does it. Ah, alright then. I'm happy to let whomever make that change, or, if no one else wants to, I'll do it since I'm the author of those lines. Thanks! Stephen signature.asc Description: Digital signature
Re: [COMMITTERS] pgsql: Add function to import operating system collations
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > On 1/19/17 7:53 AM, Tom Lane wrote: > >> Hm. I see that the patch randomly changed the way that the collation > >> owner is generated ... looks like it no longer works for mixed-case > >> usernames. Perhaps follow this model instead: > > > We could just use the numeric value, like in the attached patch. > > WFM. Btw, I noticed that BOOTSTRAP_SUPERUSERID is hard-coded as "10" > in this bit in setup_privileges(): > > " (SELECT E'=r/\"$POSTGRES_SUPERUSERNAME\"' as acl " > " UNION SELECT unnest(pg_catalog.acldefault(" > "CASE WHEN relkind = 'S' THEN 's' ELSE 'r' > END::\"char\",10::oid))" > " ) as a) " > > Is there a reasonable way to fix that? Maybe do another replace_token > call for it? Hm. I seem to recall trying to avoid having the hard-coded value there but we don't have BOOTSTRAP_SUPERUSERID defined somewhere that initdb.c could include it from, do we? It's only in catalog/pg_authid.h. We could re-define it in initdb.c, of course, and perhaps that'd be better than having it hard-coded. I'm not sure that we really want to expose BOOTSTRAP_SUPERUSERID to regular client code, or create some additional set of headers which are just for initdb and the backend.. Of course, I might be missing something here, but I'm pretty sure that was my thinking when I wrote that code. Thanks! Stephen signature.asc Description: Digital signature
[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs
pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for --single-transaction), leading to potentially completely unexpected results from a command line such as: -> pg_restore -j -1 Where a user would get neither parallel jobs nor a single-transaction. Add in validity checking of the parallel jobs option, as we already have in pg_dump, before we try to open up the archive. Also move the check that we haven't been asked to run more parallel jobs than possible on Windows to the same place, so we do all the option validity checking before opening the archive. Back-patch all the way, though for 9.2 we're adding the Windows-specific check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched originally. Discussion: https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/26e7cdb3a80d340742aeb5bfe2dbc42edfb9d34b Modified Files -- src/bin/pg_dump/pg_restore.c | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs
pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for --single-transaction), leading to potentially completely unexpected results from a command line such as: -> pg_restore -j -1 Where a user would get neither parallel jobs nor a single-transaction. Add in validity checking of the parallel jobs option, as we already have in pg_dump, before we try to open up the archive. Also move the check that we haven't been asked to run more parallel jobs than possible on Windows to the same place, so we do all the option validity checking before opening the archive. Back-patch all the way, though for 9.2 we're adding the Windows-specific check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched originally. Discussion: https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/c59a1a89035674c6efacc596d652528cebba37ec Modified Files -- src/bin/pg_dump/pg_restore.c | 16 1 file changed, 16 insertions(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs
pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for --single-transaction), leading to potentially completely unexpected results from a command line such as: -> pg_restore -j -1 Where a user would get neither parallel jobs nor a single-transaction. Add in validity checking of the parallel jobs option, as we already have in pg_dump, before we try to open up the archive. Also move the check that we haven't been asked to run more parallel jobs than possible on Windows to the same place, so we do all the option validity checking before opening the archive. Back-patch all the way, though for 9.2 we're adding the Windows-specific check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched originally. Discussion: https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/4b5f399177ecd1ae0e94606fc7c251931c5987b6 Modified Files -- src/bin/pg_dump/pg_restore.c | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs
pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for --single-transaction), leading to potentially completely unexpected results from a command line such as: -> pg_restore -j -1 Where a user would get neither parallel jobs nor a single-transaction. Add in validity checking of the parallel jobs option, as we already have in pg_dump, before we try to open up the archive. Also move the check that we haven't been asked to run more parallel jobs than possible on Windows to the same place, so we do all the option validity checking before opening the archive. Back-patch all the way, though for 9.2 we're adding the Windows-specific check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched originally. Discussion: https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/e72059f3757594c5530ce321acdbe67f0da5da13 Modified Files -- src/bin/pg_dump/pg_restore.c | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs
pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for --single-transaction), leading to potentially completely unexpected results from a command line such as: -> pg_restore -j -1 Where a user would get neither parallel jobs nor a single-transaction. Add in validity checking of the parallel jobs option, as we already have in pg_dump, before we try to open up the archive. Also move the check that we haven't been asked to run more parallel jobs than possible on Windows to the same place, so we do all the option validity checking before opening the archive. Back-patch all the way, though for 9.2 we're adding the Windows-specific check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched originally. Discussion: https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/2c72d9c5e3f2f292ebcc30a37755d87b605c7fd5 Modified Files -- src/bin/pg_dump/pg_restore.c | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_restore: Don't allow non-positive number of jobs
pg_restore: Don't allow non-positive number of jobs pg_restore will currently accept invalid values for the number of parallel jobs to run (eg: -1), unlike pg_dump which does check that the value provided is reasonable. Worse, '-1' is actually a valid, independent, parameter (as an alias for --single-transaction), leading to potentially completely unexpected results from a command line such as: -> pg_restore -j -1 Where a user would get neither parallel jobs nor a single-transaction. Add in validity checking of the parallel jobs option, as we already have in pg_dump, before we try to open up the archive. Also move the check that we haven't been asked to run more parallel jobs than possible on Windows to the same place, so we do all the option validity checking before opening the archive. Back-patch all the way, though for 9.2 we're adding the Windows-specific check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched originally. Discussion: https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/4779d6ca20f7ce89c61b7729a6c714a258586d75 Modified Files -- src/bin/pg_dump/pg_restore.c | 26 -- 1 file changed, 16 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Strict names with no matching schema
pg_dump: Strict names with no matching schema When using pg_dump --strict-names and a schema pattern which doesn't match any schemas (eg: --schema='nonexistant*'), we were incorrectly throwing an error claiming no tables were found when, really, there were no schemas found: -> pg_dump --strict-names --schema='nonexistant*' pg_dump: no matching tables were found for pattern "nonexistant*" Fix that by changing the error message to say 'schemas' instead, since that is what we are actually complaining about. Noticed while testing pg_dump error cases. Back-patch to 9.6 where --strict-names and this error message were introduced. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/abfd0095c1e1a2e3fad2696516b64871895334ec Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dump: Strict names with no matching schema
pg_dump: Strict names with no matching schema When using pg_dump --strict-names and a schema pattern which doesn't match any schemas (eg: --schema='nonexistant*'), we were incorrectly throwing an error claiming no tables were found when, really, there were no schemas found: -> pg_dump --strict-names --schema='nonexistant*' pg_dump: no matching tables were found for pattern "nonexistant*" Fix that by changing the error message to say 'schemas' instead, since that is what we are actually complaining about. Noticed while testing pg_dump error cases. Back-patch to 9.6 where --strict-names and this error message were introduced. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/22a85b3fbe85a9f1c92de90192de001b7394b4fe Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message
Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing various pg_dump error cases. Back-patch to 9.3 where parallel pg_dump was added. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/f12681079020eea53ea9a0eb994ac2ee6190770f Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message
Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing various pg_dump error cases. Back-patch to 9.3 where parallel pg_dump was added. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/96f2344f381df94fcb9b84bffc58bbc540edd842 Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message
Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing various pg_dump error cases. Back-patch to 9.3 where parallel pg_dump was added. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/7cda702363e8bfb61409bb8cbae13689b19f1648 Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message
Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing various pg_dump error cases. Back-patch to 9.3 where parallel pg_dump was added. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/2ef6fe9cbae9fe7789a35cbc5fa1bbf78c163d42 Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix invalid-parallel-jobs error message
Fix invalid-parallel-jobs error message Including the program name twice is not helpful: -> pg_dump -j -1 pg_dump: pg_dump: invalid number of parallel jobs Correct by removing the progname from the exit_horribly() call used when validating the number of parallel jobs. Noticed while testing various pg_dump error cases. Back-patch to 9.3 where parallel pg_dump was added. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/499606c806c387ba2f9a9ee773e6b92d99e27221 Modified Files -- src/bin/pg_dump/pg_dump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Add basic pg_dumpall/pg_restore TAP tests
Add basic pg_dumpall/pg_restore TAP tests For reasons unknown, pg_dumpall and pg_restore managed to escape the basic set of TAP tests that were added for pg_dump in 6bd356c3, so let's get them added now. A few minor adjustments are also made to the dump/restore tests to improve code coverage for pg_restore/pg_dumpall. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/9b815a8ff227e62442259e0fbabc5cf37e433df9 Modified Files -- src/bin/pg_dump/t/001_basic.pl | 61 +++- src/bin/pg_dump/t/002_pg_dump.pl | 8 +++--- 2 files changed, 64 insertions(+), 5 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Protect against NULL-dereference in pg_dump
Protect against NULL-dereference in pg_dump findTableByOid() is allowed to return NULL and we should therefore be checking for that case. getOwnedSeqs() and dumpSequence() shouldn't ever actually see this happen, but given odd circumstances it might and commit f9e439b1 probably shouldn't have removed that check. Pointed out by Coverity. Initial patch from Michael Paquier. Back-patch to 9.6, where that commit had removed the check. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/d74ecbc8d85eb7a2aa1d5516c5c38d6ab0cbbd82 Modified Files -- src/bin/pg_dump/pg_dump.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Protect against NULL-dereference in pg_dump
Protect against NULL-dereference in pg_dump findTableByOid() is allowed to return NULL and we should therefore be checking for that case. getOwnedSeqs() and dumpSequence() shouldn't ever actually see this happen, but given odd circumstances it might and commit f9e439b1 probably shouldn't have removed that check. Pointed out by Coverity. Initial patch from Michael Paquier. Back-patch to 9.6, where that commit had removed the check. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/8b1bf3161b360003182997b4e258b8fac78c3bdf Modified Files -- src/bin/pg_dump/pg_dump.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Update copyright for 2017
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Andres Freund writes: > > On 2017-01-03 13:02:28 -0500, Bruce Momjian wrote: > >> Yeah, I was doing parallel pulls of different branches in git via shell > >> script, and it seems the size of this commit showed me that doesn't > >> work. Sorry. > > > Shouldn't you check the results of something like this before pushing? > > Sorry for piling on, but that seems like a quite critical step. > > Actually, my takeaway from this was "don't ever use git reset on the repo". > "git revert" would have been much safer. Yeah, it would have meant that > git blame on the 9.2 branch would have some useless noise, but how much > does anyone still care about that? +1. Thanks! Stephen signature.asc Description: Digital signature
[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output
pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed out by Daniel Westermann. Back-patch to all supported branches. Discussion: https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/376d05f1db0601c018d96ba789b13184df6ec4dd Modified Files -- src/bin/pg_dump/pg_dumpall.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output
pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed out by Daniel Westermann. Back-patch to all supported branches. Discussion: https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/071538f3491d3d055a7574b8cd38a40b084a01e4 Modified Files -- src/bin/pg_dump/pg_dumpall.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output
pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed out by Daniel Westermann. Back-patch to all supported branches. Discussion: https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/d51af6570520a457a2177edb6df0471c492c3bc0 Modified Files -- src/bin/pg_dump/pg_dumpall.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output
pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed out by Daniel Westermann. Back-patch to all supported branches. Discussion: https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/846eaadd059aa6953b90ad7f2f6f16a965013748 Modified Files -- src/bin/pg_dump/pg_dumpall.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output
pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed out by Daniel Westermann. Back-patch to all supported branches. Discussion: https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/86d216c77549e200b95bed487b6fb87d99a1e789 Modified Files -- src/bin/pg_dump/pg_dumpall.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: pg_dumpall: Include --verbose option in --help output
pg_dumpall: Include --verbose option in --help output The -v/--verbose option was not included in the output from --help for pg_dumpall even though it's in the pg_dumpall documentation and has apparently been around since pg_dumpall was reimplemented in C in 2002. Fix that by adding it. Pointed out by Daniel Westermann. Back-patch to all supported branches. Discussion: https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/2ed97140c743b4a4cf725a9d1b54439d7a8dac22 Modified Files -- src/bin/pg_dump/pg_dumpall.c | 1 + 1 file changed, 1 insertion(+) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
Re: [COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
* Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Dec 23, 2016 at 9:02 PM, Stephen Frost wrote: > > Lastly, we weren't using the actual list of allowed kinds of > > objects for default privileges for completion after the 'GRANT X ON' but > > instead were completeing to what 'GRANT X ON' supports, which isn't the > > ssame at all. > > /me scratches head. 'ALTER DEFAULT PRIVILEGES ... GRANT X ON' can be followed by the literal term 'TABLES', or 'FUNCTIONS', etc. 'GRANT X ON ' can be followed by an actual table. A bit awkward to write out in a single sentence though. Thanks! Stephen signature.asc Description: Digital signature
[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the tab completion was only working for one or the other. Lastly, we weren't using the actual list of allowed kinds of objects for default privileges for completion after the 'GRANT X ON' but instead were completeing to what 'GRANT X ON' supports, which isn't the ssame at all. Address these issues by improving the forward tab-completion for ALTER DEFAULT PRIVILEGES and then constrain and correct how the tail completion is done when it is for ALTER DEFAULT PRIVILEGES. Back-patch the forward/tail tab-completion to 9.6, where we made it easy to handle such cases. For 9.5 and earlier, correct the initial tab-completion to at least be correct as far as it goes and then add a check for GRANT/REVOKE to only tab-complete when the GRANT/REVOKE is the start of the command, so we don't try to do tab-completion after we get to the GRANT/REVOKE part of the ALTER DEFAULT PRIVILEGES command, which is better than providing incorrect completions. Initial patch for master and 9.6 by Gilles Darold, though I cleaned it up and added a few comments. All bugs in the 9.5 and earlier patch are mine. Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/dc61580bd9a6ad869478c9e6f7ba76cb6314f864 Modified Files -- src/bin/psql/tab-complete.c | 57 ++--- 1 file changed, 48 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the tab completion was only working for one or the other. Lastly, we weren't using the actual list of allowed kinds of objects for default privileges for completion after the 'GRANT X ON' but instead were completeing to what 'GRANT X ON' supports, which isn't the ssame at all. Address these issues by improving the forward tab-completion for ALTER DEFAULT PRIVILEGES and then constrain and correct how the tail completion is done when it is for ALTER DEFAULT PRIVILEGES. Back-patch the forward/tail tab-completion to 9.6, where we made it easy to handle such cases. For 9.5 and earlier, correct the initial tab-completion to at least be correct as far as it goes and then add a check for GRANT/REVOKE to only tab-complete when the GRANT/REVOKE is the start of the command, so we don't try to do tab-completion after we get to the GRANT/REVOKE part of the ALTER DEFAULT PRIVILEGES command, which is better than providing incorrect completions. Initial patch for master and 9.6 by Gilles Darold, though I cleaned it up and added a few comments. All bugs in the 9.5 and earlier patch are mine. Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com Branch -- REL9_2_STABLE Details --- http://git.postgresql.org/pg/commitdiff/26b55d669092e8b69104f49d16f8cc250a7a41ee Modified Files -- src/bin/psql/tab-complete.c | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the tab completion was only working for one or the other. Lastly, we weren't using the actual list of allowed kinds of objects for default privileges for completion after the 'GRANT X ON' but instead were completeing to what 'GRANT X ON' supports, which isn't the ssame at all. Address these issues by improving the forward tab-completion for ALTER DEFAULT PRIVILEGES and then constrain and correct how the tail completion is done when it is for ALTER DEFAULT PRIVILEGES. Back-patch the forward/tail tab-completion to 9.6, where we made it easy to handle such cases. For 9.5 and earlier, correct the initial tab-completion to at least be correct as far as it goes and then add a check for GRANT/REVOKE to only tab-complete when the GRANT/REVOKE is the start of the command, so we don't try to do tab-completion after we get to the GRANT/REVOKE part of the ALTER DEFAULT PRIVILEGES command, which is better than providing incorrect completions. Initial patch for master and 9.6 by Gilles Darold, though I cleaned it up and added a few comments. All bugs in the 9.5 and earlier patch are mine. Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/16a2efdb28dfdbf705fcf7b95c981847cad7234d Modified Files -- src/bin/psql/tab-complete.c | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the tab completion was only working for one or the other. Lastly, we weren't using the actual list of allowed kinds of objects for default privileges for completion after the 'GRANT X ON' but instead were completeing to what 'GRANT X ON' supports, which isn't the ssame at all. Address these issues by improving the forward tab-completion for ALTER DEFAULT PRIVILEGES and then constrain and correct how the tail completion is done when it is for ALTER DEFAULT PRIVILEGES. Back-patch the forward/tail tab-completion to 9.6, where we made it easy to handle such cases. For 9.5 and earlier, correct the initial tab-completion to at least be correct as far as it goes and then add a check for GRANT/REVOKE to only tab-complete when the GRANT/REVOKE is the start of the command, so we don't try to do tab-completion after we get to the GRANT/REVOKE part of the ALTER DEFAULT PRIVILEGES command, which is better than providing incorrect completions. Initial patch for master and 9.6 by Gilles Darold, though I cleaned it up and added a few comments. All bugs in the 9.5 and earlier patch are mine. Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/2022d594da3233dca4a4570b1e4e5d8a83ff6163 Modified Files -- src/bin/psql/tab-complete.c | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the tab completion was only working for one or the other. Lastly, we weren't using the actual list of allowed kinds of objects for default privileges for completion after the 'GRANT X ON' but instead were completeing to what 'GRANT X ON' supports, which isn't the ssame at all. Address these issues by improving the forward tab-completion for ALTER DEFAULT PRIVILEGES and then constrain and correct how the tail completion is done when it is for ALTER DEFAULT PRIVILEGES. Back-patch the forward/tail tab-completion to 9.6, where we made it easy to handle such cases. For 9.5 and earlier, correct the initial tab-completion to at least be correct as far as it goes and then add a check for GRANT/REVOKE to only tab-complete when the GRANT/REVOKE is the start of the command, so we don't try to do tab-completion after we get to the GRANT/REVOKE part of the ALTER DEFAULT PRIVILEGES command, which is better than providing incorrect completions. Initial patch for master and 9.6 by Gilles Darold, though I cleaned it up and added a few comments. All bugs in the 9.5 and earlier patch are mine. Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/98f30a0e7d483402f2a7ebe5e6bba044c42c Modified Files -- src/bin/psql/tab-complete.c | 28 ++-- 1 file changed, 18 insertions(+), 10 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES When providing tab completion for ALTER DEFAULT PRIVILEGES, we are including the list of roles as possible options for completion after the GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time and in either order, but the tab completion was only working for one or the other. Lastly, we weren't using the actual list of allowed kinds of objects for default privileges for completion after the 'GRANT X ON' but instead were completeing to what 'GRANT X ON' supports, which isn't the ssame at all. Address these issues by improving the forward tab-completion for ALTER DEFAULT PRIVILEGES and then constrain and correct how the tail completion is done when it is for ALTER DEFAULT PRIVILEGES. Back-patch the forward/tail tab-completion to 9.6, where we made it easy to handle such cases. For 9.5 and earlier, correct the initial tab-completion to at least be correct as far as it goes and then add a check for GRANT/REVOKE to only tab-complete when the GRANT/REVOKE is the start of the command, so we don't try to do tab-completion after we get to the GRANT/REVOKE part of the ALTER DEFAULT PRIVILEGES command, which is better than providing incorrect completions. Initial patch for master and 9.6 by Gilles Darold, though I cleaned it up and added a few comments. All bugs in the 9.5 and earlier patch are mine. Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc...@dalibo.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/f3fd531a51df2a73d8517a542e6999e0186e586b Modified Files -- src/bin/psql/tab-complete.c | 57 ++--- 1 file changed, 48 insertions(+), 9 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from AlterTSConfiguration(), we're saving information about the command via EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected to true. Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION. Author: Artur Zakirov, a few additional comments by me Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it was introduced, and the fix for the ObjectAddressSet() call and setting commandCollected to true to 9.5 where those changes to ProcessUtilitySlow() were introduced. Branch -- REL9_5_STABLE Details --- http://git.postgresql.org/pg/commitdiff/e8236921773dab92f884db2685aee49fdc747cfc Modified Files -- src/backend/commands/tsearchcmds.c | 4 ++-- src/backend/tcop/utility.c | 8 +++- src/test/modules/test_ddl_deparse/Makefile | 1 + src/test/modules/test_ddl_deparse/expected/alter_ts_config.out | 8 src/test/modules/test_ddl_deparse/sql/alter_ts_config.sql | 8 5 files changed, 26 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from AlterTSConfiguration(), we're saving information about the command via EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected to true. Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION. Author: Artur Zakirov, a few additional comments by me Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it was introduced, and the fix for the ObjectAddressSet() call and setting commandCollected to true to 9.5 where those changes to ProcessUtilitySlow() were introduced. Branch -- REL9_6_STABLE Details --- http://git.postgresql.org/pg/commitdiff/f0f2e56ac28c05f930ca76c432d61909c9a12cdb Modified Files -- src/backend/commands/tsearchcmds.c | 4 ++-- src/backend/tcop/utility.c | 8 +++- src/test/modules/test_ddl_deparse/Makefile | 1 + src/test/modules/test_ddl_deparse/expected/alter_ts_config.out | 8 src/test/modules/test_ddl_deparse/sql/alter_ts_config.sql | 8 5 files changed, 26 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from AlterTSConfiguration(), we're saving information about the command via EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected to true. Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION. Author: Artur Zakirov, a few additional comments by me Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it was introduced, and the fix for the ObjectAddressSet() call and setting commandCollected to true to 9.5 where those changes to ProcessUtilitySlow() were introduced. Branch -- REL9_4_STABLE Details --- http://git.postgresql.org/pg/commitdiff/ac1ec9c1f0365293e9fdc26f06545b3b48817230 Modified Files -- src/backend/commands/tsearchcmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from AlterTSConfiguration(), we're saving information about the command via EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected to true. Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION. Author: Artur Zakirov, a few additional comments by me Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it was introduced, and the fix for the ObjectAddressSet() call and setting commandCollected to true to 9.5 where those changes to ProcessUtilitySlow() were introduced. Branch -- REL9_3_STABLE Details --- http://git.postgresql.org/pg/commitdiff/0e3aadb682f0c76f6b21ac0058e3717eb7cc2b19 Modified Files -- src/backend/commands/tsearchcmds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Use TSConfigRelationId in AlterTSConfiguration()
Use TSConfigRelationId in AlterTSConfiguration() When we are altering a text search configuration, we are getting the tuple from pg_ts_config and using its OID, so use TSConfigRelationId when invoking any post-alter hooks and setting the object address. Further, in the functions called from AlterTSConfiguration(), we're saving information about the command via EventTriggerCollectAlterTSConfig(), so we should be setting commandCollected to true. Also add a regression test to test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION. Author: Artur Zakirov, a few additional comments by me Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where it was introduced, and the fix for the ObjectAddressSet() call and setting commandCollected to true to 9.5 where those changes to ProcessUtilitySlow() were introduced. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/12bd7dd317e8f4346fb3507578aca790ede6ebea Modified Files -- src/backend/commands/tsearchcmds.c | 4 ++-- src/backend/tcop/utility.c | 8 +++- src/test/modules/test_ddl_deparse/Makefile | 1 + src/test/modules/test_ddl_deparse/expected/alter_ts_config.out | 8 src/test/modules/test_ddl_deparse/sql/alter_ts_config.sql | 8 5 files changed, 26 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers
[COMMITTERS] pgsql: Improve ALTER TABLE documentation
Improve ALTER TABLE documentation The ALTER TABLE documentation wasn't terribly clear when it came to which commands could be combined together and what it meant when they were. In particular, SET TABLESPACE *can* be combined with other commands, when it's operating against a single table, but not when multiple tables are being moved with ALL IN TABLESPACE. Further, the actions are applied together but not really in 'parallel', at least today. Pointed out by: Amit Langote Improved wording from Tom. Back-patch to 9.4, where the ALL IN TABLESPACE option was added. Discussion: https://www.postgresql.org/message-id/14c535b4-13ef-0590-1b98-76af355a0763%40lab.ntt.co.jp Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/2d1018ca56f5ddaf0bfb5b4d0133283f3e823301 Modified Files -- doc/src/sgml/ref/alter_table.sgml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers