[COMMITTERS] pgsql: Avoid core dump for empty prepared statement in an aborted trans

[Tom Lane]

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.

[Tom Lane]

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

[Andres Freund]

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.

[Andres Freund]

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.

[Andres Freund]

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

[Alvaro Herrera]

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

[Peter Eisentraut]

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

[Peter Eisentraut]

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.

[Robert Haas]

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().

[Robert Haas]

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().

[Robert Haas]

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.

[Robert Haas]

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

[Robert Haas]

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

[Stephen Frost]

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

[Stephen Frost]

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

[Stephen Frost]

* 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]

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

[Stephen Frost]

* 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

[Tom Lane]

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

[Peter Eisentraut]

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

[Tom Lane]

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

[Alvaro Herrera]

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

[Amit Kapila]

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