pgsql: Remove explicit error handling for obsolete date/time values
Remove explicit error handling for obsolete date/time values The date/time values 'current', 'invalid', and 'undefined' were removed a long time ago, but the code still contains explicit error handling for the transition. To simplify the code and avoid having to handle these values everywhere, just remove the recognition of these tokens altogether now. Reviewed-by: Michael Paquier Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/666cbae16da46b833f57ef8b12ff0bf215684d9c Modified Files -- src/backend/utils/adt/date.c | 8 src/backend/utils/adt/datetime.c | 20 src/backend/utils/adt/timestamp.c | 22 -- src/include/utils/datetime.h | 2 -- src/interfaces/ecpg/pgtypeslib/dt.h| 2 -- src/interfaces/ecpg/pgtypeslib/dt_common.c | 5 - src/interfaces/ecpg/pgtypeslib/timestamp.c | 4 src/test/regress/expected/date.out | 3 --- src/test/regress/expected/timestamp.out| 13 - src/test/regress/expected/timestamptz.out | 13 - src/test/regress/sql/date.sql | 1 - src/test/regress/sql/timestamp.sql | 4 src/test/regress/sql/timestamptz.sql | 4 13 files changed, 101 deletions(-)
pgsql: Don't call data type input functions in GUC check hooks
Don't call data type input functions in GUC check hooks Instead of calling pg_lsn_in() in check_recovery_target_lsn and timestamptz_in() in check_recovery_target_time, reorganize the respective code so that we don't raise any errors in the check hooks. The previous code tried to use PG_TRY/PG_CATCH to handle errors in a way that is not safe, so now the code contains no ereport() calls and can operate safely within the GUC error handling system. Moreover, since the interpretation of the recovery_target_time string may depend on the time zone, we cannot do the final processing of that string until all the GUC processing is done. Instead, check_recovery_target_time() now does some parsing for syntax checking, but the actual conversion to a timestamptz value is done later in the recovery code that uses it. Reported-by: Andres Freund Reviewed-by: Michael Paquier Discussion: https://www.postgresql.org/message-id/flat/20190611061115.njjwkagvxp4qujhp%40alap3.anarazel.de Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/21f428ebde39339487c271a830fed135d6032d73 Modified Files -- src/backend/access/transam/xlog.c | 15 +- src/backend/utils/adt/pg_lsn.c| 38 ++ src/backend/utils/misc/guc.c | 102 +++--- src/include/access/xlog.h | 2 +- src/include/utils/pg_lsn.h| 2 + 5 files changed, 85 insertions(+), 74 deletions(-)
pgsql: Fix breakage introduced in pg_lsn_in()
Fix breakage introduced in pg_lsn_in() Using PG_RETURN_LSN() from non-fmgr pg_lsn_in_internal() happened to work on some platforms, but should just be a plain "return". Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/2e810508f6b0d89621094445620a1bea3ceff3f1 Modified Files -- src/backend/utils/adt/pg_lsn.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Move rolenames test out of the core regression tests.
Move rolenames test out of the core regression tests.
This test script is unsafe to run in "make installcheck" mode for
(at least) two reasons: it creates and destroys some role names
that don't follow the "regress_xxx" naming convention, and it
sets and then resets the application_name GUC attached to every
existing role. While we've not had complaints, these surely are
not good things to do within a production installation, and
regress.sgml pretty clearly implies that we won't do them.
Rather than lose test coverage altogether, let's just move this
script somewhere where it will get run by "make check" but not
"make installcheck". src/test/modules/ already has that property.
Since it seems likely that we'll want other regression tests in
future that also exceed the constraints of "make installcheck",
create a generically-named src/test/modules/unsafe_tests/
directory to hold them.
Discussion: https://postgr.es/m/16638.1468620...@sss.pgh.pa.us
Branch
--
master
Details
---
https://git.postgresql.org/pg/commitdiff/c91504b958e1647f87ffb7168e61db75ca09b928
Modified Files
--
src/test/modules/Makefile | 1 +
src/test/modules/unsafe_tests/.gitignore | 4
src/test/modules/unsafe_tests/Makefile | 14 ++
src/test/modules/unsafe_tests/README | 8
.../unsafe_tests}/expected/rolenames.out | 0
.../{regress => modules/unsafe_tests}/sql/rolenames.sql| 0
src/test/regress/parallel_schedule | 2 +-
src/test/regress/serial_schedule | 1 -
8 files changed, 28 insertions(+), 2 deletions(-)
pgsql: Blind attempt to fix SSPI-auth case in 010_dump_connstr.pl.
Blind attempt to fix SSPI-auth case in 010_dump_connstr.pl. Up to now, pg_regress --config-auth had a hard-wired assumption that the target cluster uses the default bootstrap superuser name. pg_dump's 010_dump_connstr.pl TAP test uses non-default superuser names, and was klugily getting around the restriction by listing the desired superuser name as a role to "create". This is pretty confusing (or at least, it confused me). Let's make it clearer by allowing --config-auth mode to be told the bootstrap superuser name. Repurpose the existing --user switch for that, since it has no other function in --config-auth mode. Per buildfarm. I don't have an environment at hand in which I can test this fix, but the buildfarm should soon show if it works. Discussion: https://postgr.es/m/3142.1561840...@sss.pgh.pa.us Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/681cca86f5071379c4a8599ef9387b666b7e6879 Modified Files -- src/bin/pg_dump/t/010_dump_connstr.pl | 15 -- src/test/regress/pg_regress.c | 38 ++- 2 files changed, 33 insertions(+), 20 deletions(-)
pgsql: Exclude new src/test/modules/unsafe_tests directory from MSVC bu
Exclude new src/test/modules/unsafe_tests directory from MSVC build. There's nothing to build here, and that was confusing AddContrib(). Per buildfarm. Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c000a47ad1fdd4fb92c7068279d97e0c3db4f8eb Modified Files -- src/tools/msvc/Mkvcbuild.pm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
pgsql: Repair logic for reordering grouping sets optimization.
Repair logic for reordering grouping sets optimization. The logic in reorder_grouping_sets to order grouping set elements to match a pre-specified sort ordering was defective, resulting in unnecessary sort nodes (though the query output would still be correct). Repair, simplifying the code a little, and add a test. Per report from Richard Guo, though I didn't use their patch. Original bug seems to have been my fault. Backpatch back to 9.5 where grouping sets were introduced. Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2lsww0w...@mail.gmail.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4a36c77156f2ff6e07a349cddc65e5dd21abc1a8 Modified Files -- src/backend/optimizer/plan/planner.c | 39 ++ src/test/regress/expected/groupingsets.out | 13 ++ src/test/regress/sql/groupingsets.sql | 3 +++ 3 files changed, 34 insertions(+), 21 deletions(-)
pgsql: Repair logic for reordering grouping sets optimization.
Repair logic for reordering grouping sets optimization. The logic in reorder_grouping_sets to order grouping set elements to match a pre-specified sort ordering was defective, resulting in unnecessary sort nodes (though the query output would still be correct). Repair, simplifying the code a little, and add a test. Per report from Richard Guo, though I didn't use their patch. Original bug seems to have been my fault. Backpatch back to 9.5 where grouping sets were introduced. Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2lsww0w...@mail.gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/da53be23d1c5e529675e958eaee54cfed4e4dbac Modified Files -- src/backend/optimizer/plan/planner.c | 39 ++ src/test/regress/expected/groupingsets.out | 13 ++ src/test/regress/sql/groupingsets.sql | 3 +++ 3 files changed, 34 insertions(+), 21 deletions(-)
pgsql: Repair logic for reordering grouping sets optimization.
Repair logic for reordering grouping sets optimization. The logic in reorder_grouping_sets to order grouping set elements to match a pre-specified sort ordering was defective, resulting in unnecessary sort nodes (though the query output would still be correct). Repair, simplifying the code a little, and add a test. Per report from Richard Guo, though I didn't use their patch. Original bug seems to have been my fault. Backpatch back to 9.5 where grouping sets were introduced. Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2lsww0w...@mail.gmail.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/a1637caee9c77e30aaf4afb5c51e15cb67c4f3e3 Modified Files -- src/backend/optimizer/plan/planner.c | 39 ++ src/test/regress/expected/groupingsets.out | 13 ++ src/test/regress/sql/groupingsets.sql | 3 +++ 3 files changed, 34 insertions(+), 21 deletions(-)
pgsql: Repair logic for reordering grouping sets optimization.
Repair logic for reordering grouping sets optimization. The logic in reorder_grouping_sets to order grouping set elements to match a pre-specified sort ordering was defective, resulting in unnecessary sort nodes (though the query output would still be correct). Repair, simplifying the code a little, and add a test. Per report from Richard Guo, though I didn't use their patch. Original bug seems to have been my fault. Backpatch back to 9.5 where grouping sets were introduced. Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2lsww0w...@mail.gmail.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/05dc5f4767e1c5ed157b2870f05d57f3378302f4 Modified Files -- src/backend/optimizer/plan/planner.c | 39 ++ src/test/regress/expected/groupingsets.out | 13 ++ src/test/regress/sql/groupingsets.sql | 3 +++ 3 files changed, 34 insertions(+), 21 deletions(-)
pgsql: Repair logic for reordering grouping sets optimization.
Repair logic for reordering grouping sets optimization. The logic in reorder_grouping_sets to order grouping set elements to match a pre-specified sort ordering was defective, resulting in unnecessary sort nodes (though the query output would still be correct). Repair, simplifying the code a little, and add a test. Per report from Richard Guo, though I didn't use their patch. Original bug seems to have been my fault. Backpatch back to 9.5 where grouping sets were introduced. Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2lsww0w...@mail.gmail.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/793eb94e31387738c72a8d7d702a6aecc9c5edee Modified Files -- src/backend/optimizer/plan/planner.c | 39 ++ src/test/regress/expected/groupingsets.out | 13 ++ src/test/regress/sql/groupingsets.sql | 3 +++ 3 files changed, 34 insertions(+), 21 deletions(-)
pgsql: Don't read fields of a misaligned ExpandedObjectHeader or AnyArr
Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType. UBSan complains about this. Instead, cast to a suitable type requiring only 4-byte alignment. DatumGetAnyArrayP() already assumes one can cast between AnyArrayType and ArrayType, so this doesn't introduce a new assumption. Back-patch to 9.5, where AnyArrayType was introduced. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190629210334.ga1244...@rfd.leadboat.com Branch -- REL_10_STABLE Details --- https://git.postgresql.org/pg/commitdiff/cd9d48969d944c3558a77745db389e8b68b46c4b Modified Files -- src/backend/utils/adt/arrayfuncs.c | 2 +- src/include/utils/array.h | 19 +-- src/include/utils/arrayaccess.h| 4 ++-- src/include/utils/expandeddatum.h | 2 +- 4 files changed, 17 insertions(+), 10 deletions(-)
pgsql: Don't read fields of a misaligned ExpandedObjectHeader or AnyArr
Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType. UBSan complains about this. Instead, cast to a suitable type requiring only 4-byte alignment. DatumGetAnyArrayP() already assumes one can cast between AnyArrayType and ArrayType, so this doesn't introduce a new assumption. Back-patch to 9.5, where AnyArrayType was introduced. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190629210334.ga1244...@rfd.leadboat.com Branch -- REL9_6_STABLE Details --- https://git.postgresql.org/pg/commitdiff/2938aa2a5b1cebb41f9e54c1ea289c286139c21e Modified Files -- src/backend/utils/adt/arrayfuncs.c | 2 +- src/include/utils/array.h | 19 +-- src/include/utils/arrayaccess.h| 4 ++-- src/include/utils/expandeddatum.h | 2 +- 4 files changed, 17 insertions(+), 10 deletions(-)
pgsql: Don't read fields of a misaligned ExpandedObjectHeader or AnyArr
Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType. UBSan complains about this. Instead, cast to a suitable type requiring only 4-byte alignment. DatumGetAnyArrayP() already assumes one can cast between AnyArrayType and ArrayType, so this doesn't introduce a new assumption. Back-patch to 9.5, where AnyArrayType was introduced. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190629210334.ga1244...@rfd.leadboat.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/459c3cdb4ad8323bfe6bcae0186a3831e0c89c94 Modified Files -- src/backend/utils/adt/arrayfuncs.c | 2 +- src/include/utils/array.h | 19 +-- src/include/utils/arrayaccess.h| 4 ++-- src/include/utils/expandeddatum.h | 2 +- 4 files changed, 17 insertions(+), 10 deletions(-)
pgsql: Don't read fields of a misaligned ExpandedObjectHeader or AnyArr
Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType. UBSan complains about this. Instead, cast to a suitable type requiring only 4-byte alignment. DatumGetAnyArrayP() already assumes one can cast between AnyArrayType and ArrayType, so this doesn't introduce a new assumption. Back-patch to 9.5, where AnyArrayType was introduced. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190629210334.ga1244...@rfd.leadboat.com Branch -- REL_11_STABLE Details --- https://git.postgresql.org/pg/commitdiff/4b85f20f948d885875a1e1b89979e627b86e6e64 Modified Files -- src/backend/utils/adt/arrayfuncs.c | 2 +- src/include/utils/array.h | 19 +-- src/include/utils/arrayaccess.h| 4 ++-- src/include/utils/expandeddatum.h | 2 +- 4 files changed, 17 insertions(+), 10 deletions(-)
pgsql: Don't read fields of a misaligned ExpandedObjectHeader or AnyArr
Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType. UBSan complains about this. Instead, cast to a suitable type requiring only 4-byte alignment. DatumGetAnyArrayP() already assumes one can cast between AnyArrayType and ArrayType, so this doesn't introduce a new assumption. Back-patch to 9.5, where AnyArrayType was introduced. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190629210334.ga1244...@rfd.leadboat.com Branch -- REL9_5_STABLE Details --- https://git.postgresql.org/pg/commitdiff/b664b187d7ea6546ef4e0f32167a93c6a74dca08 Modified Files -- src/backend/utils/adt/arrayfuncs.c | 2 +- src/include/utils/array.h | 19 +-- src/include/utils/arrayaccess.h| 4 ++-- src/include/utils/expandeddatum.h | 2 +- 4 files changed, 17 insertions(+), 10 deletions(-)
pgsql: Fix many typos and inconsistencies
Fix many typos and inconsistencies Author: Alexander Lakhin Discussion: https://postgr.es/m/af27d1b3-a128-9d62-46e0-88f424397...@gmail.com Branch -- master Details --- https://git.postgresql.org/pg/commitdiff/c74d49d41c9e0fabeb1179dcabfb3137833ed831 Modified Files -- contrib/bloom/blutils.c| 2 +- contrib/intarray/_int_selfuncs.c | 2 +- contrib/pg_trgm/trgm_regexp.c | 6 +++--- contrib/pgcrypto/crypt-des.c | 2 +- contrib/postgres_fdw/expected/postgres_fdw.out | 2 +- contrib/postgres_fdw/sql/postgres_fdw.sql | 2 +- doc/src/sgml/diskusage.sgml| 6 +++--- src/backend/access/brin/brin_tuple.c | 4 ++-- src/backend/access/nbtree/nbtree.c | 4 ++-- src/backend/access/nbtree/nbtxlog.c| 2 +- src/backend/catalog/heap.c | 5 ++--- src/backend/executor/execExpr.c| 12 ++-- src/backend/libpq/be-fsstubs.c | 2 +- src/backend/nodes/tidbitmap.c | 2 +- src/backend/optimizer/path/equivclass.c| 9 - src/backend/optimizer/plan/createplan.c| 2 +- src/backend/optimizer/util/clauses.c | 8 src/backend/parser/analyze.c | 2 +- src/backend/parser/gram.y | 2 +- src/backend/parser/parse_target.c | 6 +++--- src/backend/postmaster/bgworker.c | 2 +- src/backend/replication/logical/logical.c | 2 +- src/backend/replication/slot.c | 4 +++- src/backend/rewrite/rewriteHandler.c | 10 +- src/backend/storage/buffer/freelist.c | 2 +- src/backend/storage/buffer/localbuf.c | 2 +- src/backend/storage/ipc/barrier.c | 6 +++--- src/backend/utils/Gen_dummy_probes.pl | 2 +- src/backend/utils/adt/arrayfuncs.c | 2 +- src/backend/utils/adt/date.c | 2 +- src/backend/utils/adt/datetime.c | 2 +- src/backend/utils/adt/oracle_compat.c | 2 +- src/backend/utils/cache/plancache.c| 2 +- src/backend/utils/mmgr/dsa.c | 2 +- src/backend/utils/mmgr/freepage.c | 2 +- src/include/access/attnum.h| 2 +- src/include/access/hash.h | 2 +- src/include/commands/event_trigger.h | 2 +- src/include/commands/extension.h | 2 -- src/include/executor/nodeCustom.h | 2 +- src/include/funcapi.h | 2 +- src/include/nodes/primnodes.h | 4 ++-- src/include/optimizer/cost.h | 2 -- src/include/optimizer/pathnode.h | 2 -- src/include/storage/fd.h | 2 +- src/include/storage/proc.h | 2 +- src/include/tcop/tcopprot.h| 5 - src/include/utils/inval.h | 2 -- src/include/utils/sortsupport.h| 4 ++-- src/interfaces/libpq/fe-auth.c | 4 ++-- 50 files changed, 76 insertions(+), 89 deletions(-)
