[COMMITTERS] pgsql: Avoid core dump for empty prepared statement in an aborted trans
Avoid core dump for empty prepared statement in an aborted transaction. Brown-paper-bag bug in commit ab1f0c822: the old code here coped with null CachedPlanSource.raw_parse_tree, the new code not so much. Per report from Dave Cramer. No regression test, because our core testing infrastructure doesn't provide any easy way to exercise this path. Fortunately, the JDBC crew test it regularly. Discussion: https://postgr.es/m/cadk3hh+ug3xcyskqw_dzonannytz1rh5yp05hjo-e4noyrx...@mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/ba61a04bc7fefeee03416d9911eb825c4897c223 Modified Files -- src/backend/tcop/postgres.c | 3 ++- 1 file changed, 2 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: Fix Assert failure induced by commit 215b43cdc.
Fix Assert failure induced by commit 215b43cdc. I'd somehow talked myself into believing that set_append_rel_size doesn't need to worry about getting back an AND clause when it applies eval_const_expressions to the result of adjust_appendrel_attrs (that is, transposing the appendrel parent's restriction clauses for one child). But that is nonsense, and Andreas Seltenreich's fuzz tester soon turned up a counterexample. Put back the make_ands_implicit step that was there before, and add a regression test covering the case. Report: https://postgr.es/m/878tq6vja6@ansel.ydns.eu Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/d479e37e3d20efad8b178e0f1e468c086a7519a8 Modified Files -- src/backend/optimizer/path/allpaths.c | 43 --- src/test/regress/expected/union.out | 30 src/test/regress/sql/union.sql| 13 +++ 3 files changed, 68 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 platform dependant regression output triggered by 69f4b9c85f
Fix platform dependant regression output triggered by 69f4b9c85f16. Due to the changed costing in that commit hash-aggregates started to be used, which results in big-endian vs. little-endian output differences. Disable hash-aggs for those tests. Author: Andres Freund, with input from Tom Lane Discussion: https://postgr.es/m/22891.1484791...@sss.pgh.pa.us Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/182200531a92204b0547d337f50b665d222af168 Modified Files -- src/test/regress/expected/tsrf.out | 6 -- src/test/regress/sql/tsrf.sql | 2 ++ 2 files changed, 6 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: Remove obsoleted code relating to targetlist SRF evaluation.
Remove obsoleted code relating to targetlist SRF evaluation. Since 69f4b9c plain expression evaluation (and thus normal projection) can't return sets of tuples anymore. Thus remove code dealing with that possibility. This will require adjustments in external code using ExecEvalExpr()/ExecProject() - that should neither be hard nor very common. Author: Andres Freund and Tom Lane Discussion: https://postgr.es/m/20160822214023.aaxz5l4igypow...@alap3.anarazel.de Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/ea15e18677fc2eff3135023e27f69ed8821554ed Modified Files -- contrib/postgres_fdw/postgres_fdw.c | 2 +- src/backend/catalog/index.c | 3 +- src/backend/catalog/partition.c | 5 +- src/backend/commands/copy.c | 2 +- src/backend/commands/prepare.c| 3 +- src/backend/commands/tablecmds.c | 3 +- src/backend/commands/typecmds.c | 2 +- src/backend/executor/execAmi.c| 44 +- src/backend/executor/execQual.c | 916 -- src/backend/executor/execScan.c | 33 +- src/backend/executor/execUtils.c | 6 - src/backend/executor/nodeAgg.c| 52 +- src/backend/executor/nodeBitmapHeapscan.c | 2 - src/backend/executor/nodeCtescan.c| 2 - src/backend/executor/nodeCustom.c | 2 - src/backend/executor/nodeForeignscan.c| 2 - src/backend/executor/nodeFunctionscan.c | 2 - src/backend/executor/nodeGather.c | 32 +- src/backend/executor/nodeGroup.c | 42 +- src/backend/executor/nodeHash.c | 2 +- src/backend/executor/nodeHashjoin.c | 61 +- src/backend/executor/nodeIndexonlyscan.c | 2 - src/backend/executor/nodeIndexscan.c | 11 +- src/backend/executor/nodeLimit.c | 19 +- src/backend/executor/nodeMergejoin.c | 63 +- src/backend/executor/nodeModifyTable.c| 4 +- src/backend/executor/nodeNestloop.c | 46 +- src/backend/executor/nodeProjectSet.c | 2 +- src/backend/executor/nodeResult.c | 36 +- src/backend/executor/nodeSamplescan.c | 8 +- src/backend/executor/nodeSeqscan.c| 2 - src/backend/executor/nodeSubplan.c| 33 +- src/backend/executor/nodeSubqueryscan.c | 2 - src/backend/executor/nodeTidscan.c| 8 +- src/backend/executor/nodeValuesscan.c | 5 +- src/backend/executor/nodeWindowAgg.c | 58 +- src/backend/executor/nodeWorktablescan.c | 2 - src/backend/optimizer/util/clauses.c | 2 +- src/backend/optimizer/util/predtest.c | 2 +- src/backend/utils/adt/domains.c | 2 +- src/backend/utils/adt/xml.c | 4 +- src/include/executor/executor.h | 9 +- src/include/nodes/execnodes.h | 17 +- src/pl/plpgsql/src/pl_exec.c | 5 +- 44 files changed, 352 insertions(+), 1208 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: Adapt python regression tests to 69f4b9c85f16.
Hi, On 2017-01-18 21:09:52 -0500, Tom Lane wrote: > I wrote: > > If you don't want an ORDER BY, maybe turn off enable_hashagg for > > these queries? But you'll get the same plan either way. > > Or not ... I forgot it has a better model of the rowcount changes now: > regression=# set enable_hashagg TO 0; > SET > regression=# explain SELECT few.dataa, count(*), min(id), max(id), > unnest('{1,1,3}'::int[]) FROM few WHERE few.id = 1 GROUP BY few.dataa, > unnest('{1,1,3}'::int[]); > QUERY PLAN > --- > GroupAggregate (cost=39.94..45.99 rows=4 width=52) >Group Key: dataa, (unnest('{1,1,3}'::integer[])) >-> Sort (cost=39.94..40.94 rows=400 width=40) > Sort Key: dataa, (unnest('{1,1,3}'::integer[])) > -> ProjectSet (cost=0.00..22.66 rows=400 width=40) >-> Seq Scan on few (cost=0.00..20.62 rows=4 width=36) > Filter: (id = 1) > (7 rows) > So which plan would you rather test? That looks good to me. Will add. Thanks, Andres -- 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 race condition in reading commit timestamps
Fix race condition in reading commit timestamps If a user requests the commit timestamp for a transaction old enough that its data is concurrently being truncated away by vacuum at just the right time, they would receive an ugly internal file-not-found error message from slru.c rather than the expected NULL return value. In a primary server, the window for the race is very small: the lookup has to occur exactly between the two calls by vacuum, and there's not a lot that happens between them (mostly just a multixact truncate). In a standby server, however, the window is larger because the truncation is executed as soon as the WAL record for it is replayed, but the advance of the oldest-Xid is not executed until the next checkpoint record. To fix in the primary, simply reverse the order of operations in vac_truncate_clog. To fix in the standby, augment the WAL truncation record so that the standby is aware of the new oldest-XID value and can apply the update immediately. WAL version bumped because of this. No backpatch, because of the low importance of the bug and its rarity. Author: Craig Ringer Reviewed-By: Petr Jelínek, Peter Eisentraut Discussion: https://postgr.es/m/CAMsr+YFhVtRQT1VAwC+WGbbxZZRzNou=n9ed-frcqkwq8h8...@mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8eace46d34ab6ac0d887aa4d3504bc4222c2e448 Modified Files -- src/backend/access/rmgrdesc/committsdesc.c | 6 +++--- src/backend/access/transam/commit_ts.c | 21 + src/backend/commands/vacuum.c | 10 +- src/include/access/commit_ts.h | 8 src/include/access/xlog_internal.h | 2 +- 5 files changed, 34 insertions(+), 13 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: Add function to import operating system collations
On 1/19/17 11:58 AM, Tom Lane 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. I have fixed that together with Amit's issue. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- 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: initdb: Fix for mixed-case superuser names
initdb: Fix for mixed-case superuser names The previous coding did not properly quote the user name before casting it to regrole. To avoid all that, just pass in BOOTSTRAP_SUPERUSERID numerically. Also fix one place where the BOOTSTRAP_SUPERUSERID was hardcoded as 10. Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8b0fec93ecc788c8d8b329d41ab795712d8dcc5a Modified Files -- src/bin/initdb/initdb.c | 5 +++-- 1 file changed, 3 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: Teach partitioning tests not to use DROP TABLE ... CASCADE.
Teach partitioning tests not to use DROP TABLE ... CASCADE. This occasionally causes failures; the order in which the affected objects are listed is not 100% consistent. Amit Langote Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/c3978149536a9c3fb837524407c58dec2b103c60 Modified Files -- src/test/regress/expected/alter_table.out | 18 ++-- src/test/regress/expected/create_table.out | 34 ++ src/test/regress/sql/alter_table.sql | 10 + src/test/regress/sql/create_table.sql | 14 ++-- 4 files changed, 26 insertions(+), 50 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: Avoid some code duplication in map_partition_varattnos().
Avoid some code duplication in map_partition_varattnos(). Code to map attribute numbers in map_partition_varattnos() duplicates what convert_tuples_by_name_map() does. Avoid that. Amit Langote, per a report from Álvaro Herrera. Discussion: http://postgr.es/m/9ce97382-54c8-deb3-9ee9-a2ec271d866b%40lab.ntt.co.jp Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/cc144155f7cdd51e19984f82da6625dc75de9fda Modified Files -- src/backend/catalog/partition.c | 21 - 1 file changed, 4 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: Fix some problems in check_new_partition_bound().
Fix some problems in check_new_partition_bound(). Account for the fact that the highest bound less than or equal to the upper bound might be either the lower or the upper bound of the overlapping partition, depending on whether the proposed partition completely contains the existing partition or merely overlaps it. Also, we need not continue searching for even greater bound in partition_bound_bsearch() once we find the first bound that is *equal* to the probe, because we don't have duplicate datums. That spends cycles needlessly. Amit Langote, per a report from Amul Sul. Cosmetic changes by me. Discussion: http://postgr.es/m/CAAJ_b94XgbqVoXMyxxs63CaqWoMS1o2gpHiU0F7yGnJBnvDc_A%40mail.gmail.com Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/8a8afe2f54c27dbb47df3853803158c5205d41ce Modified Files -- src/backend/catalog/partition.c| 64 +++--- src/test/regress/expected/create_table.out | 10 - src/test/regress/sql/create_table.sql | 4 ++ 3 files changed, 62 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
[COMMITTERS] pgsql: Fix RETURNING to work correctly with partition tuple routing.
Fix RETURNING to work correctly with partition tuple routing. In ExecInsert(), do not switch back to the root partitioned table ResultRelInfo until after we finish ExecProcessReturning(), so that RETURNING projection is done using the partition's descriptor. For the projection to work correctly, we must initialize the same for each leaf partition during ModifyTableState initialization. Amit Langote Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/05bd889904e03479a7169b1c36e0e1db13fff7cb Modified Files -- src/backend/catalog/partition.c| 8 --- src/backend/commands/tablecmds.c | 1 + src/backend/executor/execMain.c| 4 ++-- src/backend/executor/nodeModifyTable.c | 43 +++--- src/include/catalog/partition.h| 3 ++- src/test/regress/expected/insert.out | 24 ++- src/test/regress/sql/insert.sql| 16 - 7 files changed, 82 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: Fix failure to enforce partitioning contraint for internal parti
Fix failure to enforce partitioning contraint for internal partitions. When a tuple is inherited into a partitioning root, no partition constraints need to be enforced; when it is inserted into a leaf, the parent's partitioning quals needed to be enforced. The previous coding got both of those cases right. When a tuple is inserted into an intermediate level of the partitioning hierarchy (i.e. a table which is both a partition itself and in turn partitioned), it must enforce the partitioning qual inherited from its parent. That case got overlooked; repair. Amit Langote Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/39162b2030fb0a35a6bb28dc636b5a71b8df8d1c Modified Files -- src/backend/commands/copy.c | 1 - src/backend/commands/tablecmds.c | 1 - src/backend/executor/execMain.c | 42 src/include/executor/executor.h | 1 - src/test/regress/expected/insert.out | 6 ++ src/test/regress/sql/insert.sql | 5 + 6 files changed, 44 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: 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
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. regards, tom lane -- 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: > 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
Re: [COMMITTERS] pgsql: Add function to import operating system collations
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? regards, tom lane -- 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
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: > > if (superuser_password) > PG_CMD_PRINTF2("ALTER USER \"%s\" WITH PASSWORD E'%s';\n\n", > username, > escape_quotes(superuser_password)); > > although TBH that doesn't look too darn safe either. I wonder how > initdb has gotten along so far with no quote_ident() function. We could just use the numeric value, like in the attached patch. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c index eb1be100c8..75d3d6f5f6 100644 --- a/src/bin/initdb/initdb.c +++ b/src/bin/initdb/initdb.c @@ -61,6 +61,7 @@ #endif #include "catalog/catalog.h" +#include "catalog/pg_authid.h" #include "common/file_utils.h" #include "common/restricted_token.h" #include "common/username.h" @@ -1617,7 +1618,7 @@ setup_collation(FILE *cmdfd) PG_CMD_PUTS("SELECT pg_import_system_collations(if_not_exists => false, schema => 'pg_catalog');\n\n"); /* Add an SQL-standard name */ - PG_CMD_PRINTF2("INSERT INTO pg_collation (collname, collnamespace, collowner, collencoding, collcollate, collctype) VALUES ('ucs_basic', 'pg_catalog'::regnamespace, '%s'::regrole, %d, 'C', 'C');\n\n", escape_quotes(username), PG_UTF8); + PG_CMD_PRINTF2("INSERT INTO pg_collation (collname, collnamespace, collowner, collencoding, collcollate, collctype) VALUES ('ucs_basic', 'pg_catalog'::regnamespace, %u, %d, 'C', 'C');\n\n", BOOTSTRAP_SUPERUSERID, PG_UTF8); } /* -- 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
Amit Kapila writes: > On Wed, Jan 18, 2017 at 8:06 PM, Peter Eisentraut wrote: >> Add function to import operating system collations > After this commit, initdb is failing with below error on one of my VM > m/c (Linux amitkapila-centos-vm 2.6.32-358.11.1.el6.x86_64): > performing post-bootstrap initialization ... 2017-01-19 15:19:14.409 > IST [3611] FATAL: role "amitkapila" does not exist at character 150 > 2017-01-19 15:19:14.409 IST [3611] STATEMENT: INSERT INTO > pg_collation (collname, collnamespace, collowner, collencoding, > collcollate, collctype) VALUES ('ucs_basic', > 'pg_catalog'::regnamespace, 'Amitkapila'::regrole, 6, 'C', 'C'); 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: if (superuser_password) PG_CMD_PRINTF2("ALTER USER \"%s\" WITH PASSWORD E'%s';\n\n", username, escape_quotes(superuser_password)); although TBH that doesn't look too darn safe either. I wonder how initdb has gotten along so far with no quote_ident() function. regards, tom lane -- 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 negative years in make_date to represent BC years
Allow negative years in make_date to represent BC years There doesn't seem to be any reason not to allow negative years to be interpreted as BC, so do that. The documentation is pretty vague on the details of this function, so nothing needs to change there. Reported-by: Andy Abelisto, in bug #14446 Branch -- master Details --- http://git.postgresql.org/pg/commitdiff/30bcebbdcf23eb8b78e553c4b3b5eb847410ef19 Modified Files -- src/backend/utils/adt/date.c | 14 +- src/test/regress/expected/date.out | 8 ++-- src/test/regress/sql/date.sql | 2 +- 3 files changed, 16 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
Re: [COMMITTERS] pgsql: Add function to import operating system collations
On Wed, Jan 18, 2017 at 8:06 PM, Peter Eisentraut wrote: > Add function to import operating system collations > After this commit, initdb is failing with below error on one of my VM m/c (Linux amitkapila-centos-vm 2.6.32-358.11.1.el6.x86_64): ./initdb -D ../../data The files belonging to this database system will be owned by user "Amitkapila". This user must also own the server process. The database cluster will be initialized with locale "en_US.UTF-8". The default database encoding has accordingly been set to "UTF8". The default text search configuration will be set to "english". Data page checksums are disabled. fixing permissions on existing directory ../../data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 128MB selecting dynamic shared memory implementation ... posix creating configuration files ... ok running bootstrap script ... ok performing post-bootstrap initialization ... 2017-01-19 15:19:14.409 IST [3611] FATAL: role "amitkapila" does not exist at character 150 2017-01-19 15:19:14.409 IST [3611] STATEMENT: INSERT INTO pg_collation (collname, collnamespace, collowner, collencoding, collcollate, collctype) VALUES ('ucs_basic', 'pg_catalog'::regnamespace, 'Amitkapila'::regrole, 6, 'C', 'C'); I have tried on latest commit, it still fails, however trying with a commit (193a7d791ebe2adf32b36d5538e4602a90c3e0fb), everything works fine. I have noticed that if I use initdb command as below, then it passes ./initdb -D ../../data -U amitkapila echo $USER prints Amitkapila -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-committers