Initial pgperltidy run for v12.
commit : db6e2b4c52ade524f3db419d75084728e96e1f9c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 13:36:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 13:36:19 -0400 Make all the perl code look nice, too (for some value of "nice"). M src/backend/catalog/genbki.pl
M src/backend/utils/Gen_fmgrtab.pl
M src/bin/initdb/t/001_initdb.pl
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_checksums/t/002_actions.pl
M src/bin/pg_ctl/t/001_start_stop.pl
M src/bin/pg_ctl/t/004_logrotate.pl
M src/bin/pg_dump/t/001_basic.pl
M src/bin/pg_dump/t/002_pg_dump.pl
M src/bin/pg_rewind/t/002_databases.pl
M src/bin/pg_rewind/t/RewindTest.pm
M src/bin/pgbench/t/001_pgbench_with_server.pl
M src/bin/scripts/t/090_reindexdb.pl
M src/bin/scripts/t/100_vacuumdb.pl
M src/include/catalog/unused_oids
M src/interfaces/ecpg/preproc/check_rules.pl
M src/interfaces/ecpg/preproc/parse.pl
M src/test/modules/commit_ts/t/004_restart.pl
M src/test/perl/TestLib.pm
M src/test/recovery/t/001_stream_rep.pl
M src/test/recovery/t/003_recovery_targets.pl
M src/test/recovery/t/004_timeline_switch.pl
M src/test/recovery/t/013_crash_restart.pl
M src/test/recovery/t/015_promotion_pages.pl
M src/test/recovery/t/016_min_consistency.pl
M src/test/ssl/t/001_ssltests.pl
M src/test/ssl/t/002_scram.pl
M src/test/subscription/t/002_types.pl
M src/test/subscription/t/011_generated.pl
M src/test/subscription/t/012_collation.pl
M src/test/subscription/t/100_bugs.pl
M src/tools/gen_keywordlist.pl
M src/tools/msvc/Install.pm
M src/tools/msvc/Solution.pm
M src/tools/msvc/build.pl
M src/tools/msvc/install.pl
M src/tools/msvc/mkvcbuild.pl
M src/tools/msvc/vcregress.pl
Phase 2 pgindent run for v12.
commit : 8255c7a5eeba8f1a38b7a431c04909bde4f5e67d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 13:04:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 13:04:48 -0400 Switch to 2.1 version of pg_bsd_indent. This formats
multiline function declarations "correctly", that is with
additional lines of parameter declarations indented to match
where the first line's left parenthesis is.
Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com M contrib/amcheck/verify_nbtree.c
M contrib/auto_explain/auto_explain.c
M contrib/bloom/bloom.h
M contrib/btree_gist/btree_utils_num.h
M contrib/btree_gist/btree_utils_var.h
M contrib/dblink/dblink.c
M contrib/file_fdw/file_fdw.c
M contrib/intarray/_int_selfuncs.c
M contrib/jsonb_plpython/jsonb_plpython.c
M contrib/ltree/lquery_op.c
M contrib/ltree/ltree.h
M contrib/pageinspect/brinfuncs.c
M contrib/pageinspect/rawpage.c
M contrib/pg_stat_statements/pg_stat_statements.c
M contrib/pg_trgm/trgm.h
M contrib/pg_trgm/trgm_regexp.c
M contrib/pg_visibility/pg_visibility.c
M contrib/pgcrypto/imath.c
M contrib/pgcrypto/mbuf.h
M contrib/pgcrypto/pgp-decrypt.c
M contrib/pgcrypto/pgp.h
M contrib/pgcrypto/px-crypt.h
M contrib/pgstattuple/pgstattuple.c
M contrib/postgres_fdw/connection.c
M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/postgres_fdw.h
M contrib/sepgsql/sepgsql.h
M contrib/tablefunc/tablefunc.c
M contrib/test_decoding/test_decoding.c
M contrib/tsm_system_rows/tsm_system_rows.c
M contrib/tsm_system_time/tsm_system_time.c
M contrib/xml2/xpath.c
M src/backend/access/brin/brin.c
M src/backend/access/brin/brin_inclusion.c
M src/backend/access/brin/brin_minmax.c
M src/backend/access/brin/brin_pageops.c
M src/backend/access/brin/brin_revmap.c
M src/backend/access/brin/brin_tuple.c
M src/backend/access/common/printtup.c
M src/backend/access/common/reloptions.c
M src/backend/access/gin/ginbtree.c
M src/backend/access/gin/gindatapage.c
M src/backend/access/gin/ginentrypage.c
M src/backend/access/gist/gist.c
M src/backend/access/gist/gistbuild.c
M src/backend/access/gist/gistbuildbuffers.c
M src/backend/access/gist/gistproc.c
M src/backend/access/gist/gistvacuum.c
M src/backend/access/hash/hash.c
M src/backend/access/hash/hashinsert.c
M src/backend/access/hash/hashpage.c
M src/backend/access/hash/hashsearch.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/heap/pruneheap.c
M src/backend/access/heap/syncscan.c
M src/backend/access/heap/tuptoaster.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/access/index/indexam.c
M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtpage.c
M src/backend/access/nbtree/nbtree.c
M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/nbtree/nbtsplitloc.c
M src/backend/access/nbtree/nbtutils.c
M src/backend/access/tablesample/bernoulli.c
M src/backend/access/tablesample/system.c
M src/backend/access/transam/clog.c
M src/backend/access/transam/commit_ts.c
M src/backend/access/transam/generic_xlog.c
M src/backend/access/transam/multixact.c
M src/backend/access/transam/slru.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xloginsert.c
M src/backend/access/transam/xlogreader.c
M src/backend/catalog/aclchk.c
M src/backend/catalog/dependency.c
M src/backend/catalog/heap.c
M src/backend/catalog/index.c
M src/backend/catalog/namespace.c
M src/backend/catalog/objectaddress.c
M src/backend/catalog/partition.c
M src/backend/catalog/pg_aggregate.c
M src/backend/catalog/pg_operator.c
M src/backend/catalog/pg_proc.c
M src/backend/catalog/pg_shdepend.c
M src/backend/catalog/toasting.c
M src/backend/commands/analyze.c
M src/backend/commands/async.c
M src/backend/commands/cluster.c
M src/backend/commands/copy.c
M src/backend/commands/dbcommands.c
M src/backend/commands/dropcmds.c
M src/backend/commands/event_trigger.c
M src/backend/commands/explain.c
M src/backend/commands/extension.c
M src/backend/commands/indexcmds.c
M src/backend/commands/lockcmds.c
M src/backend/commands/matview.c
M src/backend/commands/opclasscmds.c
M src/backend/commands/policy.c
M src/backend/commands/prepare.c
M src/backend/commands/proclang.c
M src/backend/commands/publicationcmds.c
M src/backend/commands/sequence.c
M src/backend/commands/statscmds.c
M src/backend/commands/tablecmds.c
M src/backend/commands/tablespace.c
M src/backend/commands/trigger.c
M src/backend/commands/tsearchcmds.c
M src/backend/commands/typecmds.c
M src/backend/commands/user.c
M src/backend/commands/vacuum.c
M src/backend/executor/execCurrent.c
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/backend/executor/execIndexing.c
M src/backend/executor/execMain.c
M src/backend/executor/execParallel.c
M src/backend/executor/execPartition.c
M src/backend/executor/execSRF.c
M src/backend/executor/execTuples.c
M src/backend/executor/functions.c
M src/backend/executor/instrument.c
M src/backend/executor/nodeAgg.c
M src/backend/executor/nodeBitmapHeapscan.c
M src/backend/executor/nodeGatherMerge.c
M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/executor/nodeIndexscan.c
M src/backend/executor/nodeModifyTable.c
M src/backend/executor/nodeSubplan.c
M src/backend/executor/nodeWindowAgg.c
M src/backend/executor/spi.c
M src/backend/jit/llvm/llvmjit_expr.c
M src/backend/lib/bloomfilter.c
M src/backend/lib/dshash.c
M src/backend/lib/integerset.c
M src/backend/lib/pairingheap.c
M src/backend/libpq/auth-scram.c
M src/backend/libpq/auth.c
M src/backend/libpq/be-gssapi-common.h
M src/backend/libpq/be-secure-openssl.c
M src/backend/libpq/hba.c
M src/backend/libpq/ifaddr.c
M src/backend/nodes/nodeFuncs.c
M src/backend/nodes/tidbitmap.c
M src/backend/optimizer/geqo/geqo_eval.c
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/path/clausesel.c
M src/backend/optimizer/path/costsize.c
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/path/indxpath.c
M src/backend/optimizer/path/joinpath.c
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/path/pathkeys.c
M src/backend/optimizer/plan/analyzejoins.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/initsplan.c
M src/backend/optimizer/plan/planagg.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/setrefs.c
M src/backend/optimizer/plan/subselect.c
M src/backend/optimizer/prep/prepjointree.c
M src/backend/optimizer/prep/preptlist.c
M src/backend/optimizer/prep/prepunion.c
M src/backend/optimizer/util/appendinfo.c
M src/backend/optimizer/util/clauses.c
M src/backend/optimizer/util/inherit.c
M src/backend/optimizer/util/orclauses.c
M src/backend/optimizer/util/pathnode.c
M src/backend/optimizer/util/plancat.c
M src/backend/optimizer/util/predtest.c
M src/backend/optimizer/util/relnode.c
M src/backend/optimizer/util/restrictinfo.c
M src/backend/optimizer/util/tlist.c
M src/backend/optimizer/util/var.c
M src/backend/parser/analyze.c
M src/backend/parser/parse_agg.c
M src/backend/parser/parse_clause.c
M src/backend/parser/parse_coerce.c
M src/backend/parser/parse_collate.c
M src/backend/parser/parse_expr.c
M src/backend/parser/parse_func.c
M src/backend/parser/parse_oper.c
M src/backend/parser/parse_param.c
M src/backend/parser/parse_relation.c
M src/backend/parser/parse_target.c
M src/backend/parser/parse_type.c
M src/backend/parser/parse_utilcmd.c
M src/backend/partitioning/partbounds.c
M src/backend/partitioning/partprune.c
M src/backend/port/sysv_sema.c
M src/backend/port/sysv_shmem.c
M src/backend/postmaster/autovacuum.c
M src/backend/postmaster/pgstat.c
M src/backend/postmaster/postmaster.c
M src/backend/postmaster/syslogger.c
M src/backend/regex/regcomp.c
M src/backend/regex/regprefix.c
M src/backend/replication/basebackup.c
M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/backend/replication/logical/decode.c
M src/backend/replication/logical/logical.c
M src/backend/replication/logical/proto.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/pgoutput/pgoutput.c
M src/backend/replication/syncrep.c
M src/backend/rewrite/rewriteDefine.c
M src/backend/rewrite/rewriteHandler.c
M src/backend/rewrite/rewriteManip.c
M src/backend/rewrite/rowsecurity.c
M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
M src/backend/statistics/mvdistinct.c
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/buffer/freelist.c
M src/backend/storage/file/fd.c
M src/backend/storage/file/reinit.c
M src/backend/storage/freespace/freespace.c
M src/backend/storage/ipc/dsm.c
M src/backend/storage/ipc/dsm_impl.c
M src/backend/storage/ipc/latch.c
M src/backend/storage/ipc/procarray.c
M src/backend/storage/ipc/shm_mq.c
M src/backend/storage/ipc/standby.c
M src/backend/storage/lmgr/deadlock.c
M src/backend/storage/lmgr/lock.c
M src/backend/storage/lmgr/predicate.c
M src/backend/storage/smgr/md.c
M src/backend/tcop/fastpath.c
M src/backend/tcop/pquery.c
M src/backend/tcop/utility.c
M src/backend/tsearch/ts_selfuncs.c
M src/backend/tsearch/ts_typanalyze.c
M src/backend/utils/adt/acl.c
M src/backend/utils/adt/array_expanded.c
M src/backend/utils/adt/array_selfuncs.c
M src/backend/utils/adt/array_typanalyze.c
M src/backend/utils/adt/arrayfuncs.c
M src/backend/utils/adt/ascii.c
M src/backend/utils/adt/datetime.c
M src/backend/utils/adt/expandedrecord.c
M src/backend/utils/adt/formatting.c
M src/backend/utils/adt/geo_ops.c
M src/backend/utils/adt/inet_cidr_ntop.c
M src/backend/utils/adt/json.c
M src/backend/utils/adt/jsonb.c
M src/backend/utils/adt/jsonb_gin.c
M src/backend/utils/adt/jsonb_util.c
M src/backend/utils/adt/jsonfuncs.c
M src/backend/utils/adt/jsonpath.c
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/adt/like.c
M src/backend/utils/adt/like_support.c
M src/backend/utils/adt/network.c
M src/backend/utils/adt/network_selfuncs.c
M src/backend/utils/adt/network_spgist.c
M src/backend/utils/adt/numeric.c
M src/backend/utils/adt/oracle_compat.c
M src/backend/utils/adt/rangetypes.c
M src/backend/utils/adt/rangetypes_gist.c
M src/backend/utils/adt/rangetypes_selfuncs.c
M src/backend/utils/adt/rangetypes_spgist.c
M src/backend/utils/adt/rangetypes_typanalyze.c
M src/backend/utils/adt/regexp.c
M src/backend/utils/adt/regproc.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/adt/ruleutils.c
M src/backend/utils/adt/selfuncs.c
M src/backend/utils/adt/varbit.c
M src/backend/utils/adt/varlena.c
M src/backend/utils/adt/windowfuncs.c
M src/backend/utils/adt/xml.c
M src/backend/utils/cache/catcache.c
M src/backend/utils/cache/evtcache.c
M src/backend/utils/cache/plancache.c
M src/backend/utils/cache/relcache.c
M src/backend/utils/cache/relmapper.c
M src/backend/utils/cache/typcache.c
M src/backend/utils/fmgr/dfmgr.c
M src/backend/utils/fmgr/fmgr.c
M src/backend/utils/fmgr/funcapi.c
M src/backend/utils/mb/mbutils.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/tzparser.c
M src/backend/utils/mmgr/aset.c
M src/backend/utils/mmgr/dsa.c
M src/backend/utils/mmgr/freepage.c
M src/backend/utils/mmgr/generation.c
M src/backend/utils/mmgr/mcxt.c
M src/backend/utils/mmgr/slab.c
M src/backend/utils/resowner/resowner.c
M src/backend/utils/sort/logtape.c
M src/backend/utils/sort/sharedtuplestore.c
M src/backend/utils/sort/tuplesort.c
M src/backend/utils/sort/tuplestore.c
M src/backend/utils/time/snapmgr.c
M src/bin/initdb/findtimezone.c
M src/bin/initdb/initdb.c
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/pg_recvlogical.c
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/receivelog.h
M src/bin/pg_basebackup/streamutil.h
M src/bin/pg_basebackup/walmethods.h
M src/bin/pg_dump/common.c
M src/bin/pg_dump/compress_io.c
M src/bin/pg_dump/compress_io.h
M src/bin/pg_dump/dumputils.c
M src/bin/pg_dump/dumputils.h
M src/bin/pg_dump/parallel.c
M src/bin/pg_dump/parallel.h
M src/bin/pg_dump/pg_backup.h
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_archiver.h
M src/bin/pg_dump/pg_backup_db.h
M src/bin/pg_dump/pg_backup_directory.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/pg_dump_sort.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_rewind/copy_fetch.c
M src/bin/pg_rewind/filemap.c
M src/bin/pg_rewind/filemap.h
M src/bin/pg_rewind/parsexlog.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pg_rewind/pg_rewind.h
M src/bin/pg_upgrade/info.c
M src/bin/pg_upgrade/option.c
M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pgbench/pgbench.c
M src/bin/pgbench/pgbench.h
M src/bin/psql/command.c
M src/bin/psql/command.h
M src/bin/psql/common.h
M src/bin/psql/copy.h
M src/bin/psql/crosstabview.c
M src/bin/psql/describe.c
M src/bin/psql/startup.c
M src/bin/psql/stringutils.h
M src/bin/psql/tab-complete.c
M src/bin/psql/variables.h
M src/bin/scripts/clusterdb.c
M src/bin/scripts/common.h
M src/bin/scripts/reindexdb.c
M src/bin/scripts/vacuumdb.c
M src/common/file_utils.c
M src/common/ip.c
M src/fe_utils/print.c
M src/include/access/amvalidate.h
M src/include/access/brin_internal.h
M src/include/access/brin_pageops.h
M src/include/access/brin_revmap.h
M src/include/access/brin_tuple.h
M src/include/access/clog.h
M src/include/access/commit_ts.h
M src/include/access/genam.h
M src/include/access/generic_xlog.h
M src/include/access/gin.h
M src/include/access/gin_private.h
M src/include/access/gist_private.h
M src/include/access/gistscan.h
M src/include/access/hash.h
M src/include/access/heapam.h
M src/include/access/heapam_xlog.h
M src/include/access/hio.h
M src/include/access/htup.h
M src/include/access/htup_details.h
M src/include/access/itup.h
M src/include/access/multixact.h
M src/include/access/nbtree.h
M src/include/access/parallel.h
M src/include/access/printsimple.h
M src/include/access/printtup.h
M src/include/access/relation.h
M src/include/access/reloptions.h
M src/include/access/rewriteheap.h
M src/include/access/skey.h
M src/include/access/slru.h
M src/include/access/spgist.h
M src/include/access/spgist_private.h
M src/include/access/table.h
M src/include/access/tableam.h
M src/include/access/timeline.h
M src/include/access/transam.h
M src/include/access/tupconvert.h
M src/include/access/tupdesc.h
M src/include/access/tuptoaster.h
M src/include/access/twophase.h
M src/include/access/twophase_rmgr.h
M src/include/access/visibilitymap.h
M src/include/access/xact.h
M src/include/access/xlog.h
M src/include/access/xlog_internal.h
M src/include/access/xloginsert.h
M src/include/access/xlogreader.h
M src/include/access/xlogutils.h
M src/include/bootstrap/bootstrap.h
M src/include/c.h
M src/include/catalog/catalog.h
M src/include/catalog/dependency.h
M src/include/catalog/heap.h
M src/include/catalog/index.h
M src/include/catalog/indexing.h
M src/include/catalog/namespace.h
M src/include/catalog/objectaccess.h
M src/include/catalog/objectaddress.h
M src/include/catalog/partition.h
M src/include/catalog/pg_aggregate.h
M src/include/catalog/pg_collation.h
M src/include/catalog/pg_constraint.h
M src/include/catalog/pg_conversion.h
M src/include/catalog/pg_db_role_setting.h
M src/include/catalog/pg_enum.h
M src/include/catalog/pg_inherits.h
M src/include/catalog/pg_operator.h
M src/include/catalog/pg_proc.h
M src/include/catalog/pg_publication.h
M src/include/catalog/pg_range.h
M src/include/catalog/pg_subscription_rel.h
M src/include/catalog/pg_type.h
M src/include/catalog/storage.h
M src/include/catalog/toasting.h
M src/include/commands/alter.h
M src/include/commands/async.h
M src/include/commands/cluster.h
M src/include/commands/copy.h
M src/include/commands/createas.h
M src/include/commands/defrem.h
M src/include/commands/event_trigger.h
M src/include/commands/explain.h
M src/include/commands/extension.h
M src/include/commands/matview.h
M src/include/commands/policy.h
M src/include/commands/portalcmds.h
M src/include/commands/prepare.h
M src/include/commands/schemacmds.h
M src/include/commands/seclabel.h
M src/include/commands/subscriptioncmds.h
M src/include/commands/tablecmds.h
M src/include/commands/trigger.h
M src/include/commands/typecmds.h
M src/include/commands/vacuum.h
M src/include/commands/view.h
M src/include/common/config_info.h
M src/include/common/controldata_utils.h
M src/include/common/ip.h
M src/include/common/md5.h
M src/include/common/pg_lzcompress.h
M src/include/common/relpath.h
M src/include/common/scram-common.h
M src/include/common/sha2.h
M src/include/common/string.h
M src/include/executor/execExpr.h
M src/include/executor/execParallel.h
M src/include/executor/execPartition.h
M src/include/executor/execdesc.h
M src/include/executor/executor.h
M src/include/executor/functions.h
M src/include/executor/nodeBitmapHeapscan.h
M src/include/executor/nodeCustom.h
M src/include/executor/nodeForeignscan.h
M src/include/executor/nodeGatherMerge.h
M src/include/executor/nodeHash.h
M src/include/executor/nodeHashjoin.h
M src/include/executor/nodeIndexonlyscan.h
M src/include/executor/nodeIndexscan.h
M src/include/executor/nodeSeqscan.h
M src/include/executor/spi.h
M src/include/executor/tqueue.h
M src/include/executor/tstoreReceiver.h
M src/include/executor/tuptable.h
M src/include/fe_utils/mbprint.h
M src/include/fe_utils/print.h
M src/include/fe_utils/psqlscan.h
M src/include/fe_utils/psqlscan_int.h
M src/include/fe_utils/string_utils.h
M src/include/fmgr.h
M src/include/foreign/fdwapi.h
M src/include/foreign/foreign.h
M src/include/funcapi.h
M src/include/getaddrinfo.h
M src/include/getopt_long.h
M src/include/lib/binaryheap.h
M src/include/lib/bloomfilter.h
M src/include/lib/dshash.h
M src/include/lib/knapsack.h
M src/include/lib/pairingheap.h
M src/include/lib/rbtree.h
M src/include/lib/simplehash.h
M src/include/lib/stringinfo.h
M src/include/libpq/be-fsstubs.h
M src/include/libpq/crypt.h
M src/include/libpq/hba.h
M src/include/libpq/ifaddr.h
M src/include/libpq/libpq.h
M src/include/libpq/pqformat.h
M src/include/libpq/scram.h
M src/include/mb/pg_wchar.h
M src/include/miscadmin.h
M src/include/nodes/extensible.h
M src/include/nodes/makefuncs.h
M src/include/nodes/nodeFuncs.h
M src/include/nodes/nodes.h
M src/include/nodes/print.h
M src/include/nodes/tidbitmap.h
M src/include/optimizer/appendinfo.h
M src/include/optimizer/clauses.h
M src/include/optimizer/cost.h
M src/include/optimizer/geqo.h
M src/include/optimizer/geqo_recombination.h
M src/include/optimizer/geqo_selection.h
M src/include/optimizer/inherit.h
M src/include/optimizer/joininfo.h
M src/include/optimizer/optimizer.h
M src/include/optimizer/paramassign.h
M src/include/optimizer/pathnode.h
M src/include/optimizer/paths.h
M src/include/optimizer/placeholder.h
M src/include/optimizer/plancat.h
M src/include/optimizer/planmain.h
M src/include/optimizer/planner.h
M src/include/optimizer/restrictinfo.h
M src/include/optimizer/subselect.h
M src/include/optimizer/tlist.h
M src/include/parser/analyze.h
M src/include/parser/gramparse.h
M src/include/parser/parse_agg.h
M src/include/parser/parse_clause.h
M src/include/parser/parse_coerce.h
M src/include/parser/parse_cte.h
M src/include/parser/parse_func.h
M src/include/parser/parse_node.h
M src/include/parser/parse_oper.h
M src/include/parser/parse_param.h
M src/include/parser/parse_relation.h
M src/include/parser/parse_target.h
M src/include/parser/parse_type.h
M src/include/parser/parse_utilcmd.h
M src/include/parser/parsetree.h
M src/include/parser/scanner.h
M src/include/parser/scansup.h
M src/include/partitioning/partbounds.h
M src/include/partitioning/partdesc.h
M src/include/partitioning/partprune.h
M src/include/pgstat.h
M src/include/pgtar.h
M src/include/pgtime.h
M src/include/port.h
M src/include/postmaster/autovacuum.h
M src/include/postmaster/bgworker.h
M src/include/regex/regex.h
M src/include/regex/regexport.h
M src/include/replication/decode.h
M src/include/replication/logical.h
M src/include/replication/logicalfuncs.h
M src/include/replication/logicalproto.h
M src/include/replication/logicalrelation.h
M src/include/replication/message.h
M src/include/replication/origin.h
M src/include/replication/reorderbuffer.h
M src/include/replication/slot.h
M src/include/replication/snapbuild.h
M src/include/replication/walreceiver.h
M src/include/replication/worker_internal.h
M src/include/rewrite/rewriteDefine.h
M src/include/rewrite/rewriteHandler.h
M src/include/rewrite/rewriteManip.h
M src/include/rewrite/rowsecurity.h
M src/include/statistics/extended_stats_internal.h
M src/include/statistics/statistics.h
M src/include/storage/buf_internals.h
M src/include/storage/bufmgr.h
M src/include/storage/bufpage.h
M src/include/storage/dsm.h
M src/include/storage/dsm_impl.h
M src/include/storage/fd.h
M src/include/storage/freespace.h
M src/include/storage/fsm_internals.h
M src/include/storage/itemptr.h
M src/include/storage/latch.h
M src/include/storage/lmgr.h
M src/include/storage/lock.h
M src/include/storage/md.h
M src/include/storage/pg_shmem.h
M src/include/storage/predicate.h
M src/include/storage/predicate_internals.h
M src/include/storage/procarray.h
M src/include/storage/procsignal.h
M src/include/storage/reinit.h
M src/include/storage/sharedfileset.h
M src/include/storage/shm_mq.h
M src/include/storage/shmem.h
M src/include/storage/sinval.h
M src/include/storage/smgr.h
M src/include/storage/standby.h
M src/include/storage/standbydefs.h
M src/include/storage/sync.h
M src/include/tcop/pquery.h
M src/include/tcop/tcopprot.h
M src/include/tcop/utility.h
M src/include/tsearch/ts_locale.h
M src/include/tsearch/ts_public.h
M src/include/tsearch/ts_utils.h
M src/include/utils/acl.h
M src/include/utils/array.h
M src/include/utils/builtins.h
M src/include/utils/catcache.h
M src/include/utils/datetime.h
M src/include/utils/datum.h
M src/include/utils/dsa.h
M src/include/utils/elog.h
M src/include/utils/expandeddatum.h
M src/include/utils/expandedrecord.h
M src/include/utils/float.h
M src/include/utils/freepage.h
M src/include/utils/guc.h
M src/include/utils/guc_tables.h
M src/include/utils/hashutils.h
M src/include/utils/hsearch.h
M src/include/utils/index_selfuncs.h
M src/include/utils/inval.h
M src/include/utils/jsonapi.h
M src/include/utils/jsonb.h
M src/include/utils/jsonpath.h
M src/include/utils/logtape.h
M src/include/utils/lsyscache.h
M src/include/utils/memutils.h
M src/include/utils/numeric.h
M src/include/utils/palloc.h
M src/include/utils/pg_locale.h
M src/include/utils/plancache.h
M src/include/utils/portal.h
M src/include/utils/ps_status.h
M src/include/utils/rangetypes.h
M src/include/utils/regproc.h
M src/include/utils/relcache.h
M src/include/utils/relmapper.h
M src/include/utils/resowner.h
M src/include/utils/resowner_private.h
M src/include/utils/ruleutils.h
M src/include/utils/sampling.h
M src/include/utils/selfuncs.h
M src/include/utils/sharedtuplestore.h
M src/include/utils/snapmgr.h
M src/include/utils/sortsupport.h
M src/include/utils/spccache.h
M src/include/utils/syscache.h
M src/include/utils/timestamp.h
M src/include/utils/tuplesort.h
M src/include/utils/tuplestore.h
M src/include/utils/typcache.h
M src/include/utils/varlena.h
M src/include/utils/xml.h
M src/include/windowapi.h
M src/interfaces/ecpg/ecpglib/ecpglib_extern.h
M src/interfaces/ecpg/ecpglib/prepare.c
M src/interfaces/ecpg/pgtypeslib/dt.h
M src/interfaces/ecpg/preproc/type.c
M src/interfaces/ecpg/preproc/type.h
M src/interfaces/libpq/fe-auth-scram.c
M src/interfaces/libpq/fe-auth.h
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-exec.c
M src/interfaces/libpq/fe-gssapi-common.h
M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/fe-print.c
M src/interfaces/libpq/fe-protocol3.c
M src/interfaces/libpq/fe-secure-common.h
M src/interfaces/libpq/fe-secure-openssl.c
M src/interfaces/libpq/libpq-events.h
M src/interfaces/libpq/libpq-fe.h
M src/interfaces/libpq/libpq-int.h
M src/interfaces/libpq/pqexpbuffer.h
M src/pl/plperl/plperl.c
M src/pl/plpgsql/src/pl_comp.c
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/plpgsql.h
M src/pl/plpython/plpy_elog.c
M src/pl/plpython/plpy_elog.h
M src/pl/plpython/plpy_exec.c
M src/pl/plpython/plpy_plpymodule.c
M src/pl/plpython/plpy_spi.c
M src/pl/plpython/plpy_typeio.c
M src/pl/plpython/plpy_typeio.h
M src/pl/tcl/pltcl.c
M src/port/inet_net_ntop.c
M src/port/path.c
M src/port/qsort.c
M src/port/qsort_arg.c
M src/port/snprintf.c
M src/test/isolation/isolationtester.c
M src/test/modules/test_shm_mq/setup.c
M src/test/modules/test_shm_mq/test.c
M src/test/modules/test_shm_mq/test_shm_mq.h
M src/test/modules/test_shm_mq/worker.c
M src/test/regress/pg_regress.h
M src/timezone/localtime.c
M src/timezone/pgtz.c
M src/timezone/pgtz.h
M src/timezone/strftime.c
M src/timezone/zic.c
M src/tools/pgindent/pgindent
M src/tutorial/funcs.c
Initial pgindent run for v12.
commit : be76af171cdb3e7465c4ef234af403f97ad79b7b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 12:55:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 12:55:34 -0400 This is still using the 2.0 version of pg_bsd_indent.
I thought it would be good to commit this separately,
so as to document the differences between 2.0 and 2.1 behavior.
Discussion: https://postgr.es/m/16296.1558103386@sss.pgh.pa.us M contrib/amcheck/verify_nbtree.c
M contrib/cube/cube.c
M contrib/file_fdw/file_fdw.c
M contrib/intarray/_int_gist.c
M contrib/intarray/_int_tool.c
M contrib/pg_stat_statements/pg_stat_statements.c
M contrib/pgcrypto/imath.c
M contrib/pgcrypto/imath.h
M contrib/pgstattuple/pgstattuple.c
M contrib/postgres_fdw/postgres_fdw.c
M src/backend/access/common/heaptuple.c
M src/backend/access/gin/ginvacuum.c
M src/backend/access/gin/ginxlog.c
M src/backend/access/gist/gistutil.c
M src/backend/access/hash/hashfunc.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/heap/rewriteheap.c
M src/backend/access/heap/tuptoaster.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/nbtree/nbtutils.c
M src/backend/access/spgist/spgscan.c
M src/backend/access/spgist/spgtextproc.c
M src/backend/access/spgist/spgvacuum.c
M src/backend/access/table/tableam.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/catalog/aclchk.c
M src/backend/catalog/catalog.c
M src/backend/catalog/heap.c
M src/backend/catalog/index.c
M src/backend/catalog/objectaddress.c
M src/backend/catalog/pg_aggregate.c
M src/backend/catalog/pg_proc.c
M src/backend/catalog/pg_publication.c
M src/backend/catalog/storage.c
M src/backend/commands/amcmds.c
M src/backend/commands/cluster.c
M src/backend/commands/constraint.c
M src/backend/commands/dbcommands.c
M src/backend/commands/explain.c
M src/backend/commands/extension.c
M src/backend/commands/indexcmds.c
M src/backend/commands/statscmds.c
M src/backend/commands/tablecmds.c
M src/backend/commands/tablespace.c
M src/backend/commands/trigger.c
M src/backend/commands/vacuum.c
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/backend/executor/execMain.c
M src/backend/executor/execParallel.c
M src/backend/executor/execPartition.c
M src/backend/executor/execReplication.c
M src/backend/executor/execScan.c
M src/backend/executor/execTuples.c
M src/backend/executor/functions.c
M src/backend/executor/nodeAgg.c
M src/backend/executor/nodeGatherMerge.c
M src/backend/executor/nodeHashjoin.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/executor/nodeIndexscan.c
M src/backend/executor/nodeLockRows.c
M src/backend/executor/nodeModifyTable.c
M src/backend/executor/nodeSeqscan.c
M src/backend/executor/nodeSubplan.c
M src/backend/executor/nodeSubqueryscan.c
M src/backend/libpq/auth.c
M src/backend/libpq/be-secure-openssl.c
M src/backend/nodes/bitmapset.c
M src/backend/optimizer/path/clausesel.c
M src/backend/optimizer/util/inherit.c
M src/backend/optimizer/util/pathnode.c
M src/backend/parser/parse_utilcmd.c
M src/backend/partitioning/partdesc.c
M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/slotfuncs.c
M src/backend/replication/syncrep.c
M src/backend/replication/walreceiver.c
M src/backend/replication/walsender.c
M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/file/fd.c
M src/backend/storage/ipc/latch.c
M src/backend/storage/ipc/pmsignal.c
M src/backend/storage/ipc/signalfuncs.c
M src/backend/storage/lmgr/lmgr.c
M src/backend/storage/smgr/smgr.c
M src/backend/storage/sync/sync.c
M src/backend/tcop/dest.c
M src/backend/utils/adt/formatting.c
M src/backend/utils/adt/genfile.c
M src/backend/utils/adt/geo_ops.c
M src/backend/utils/adt/json.c
M src/backend/utils/adt/jsonb.c
M src/backend/utils/adt/like.c
M src/backend/utils/adt/like_support.c
M src/backend/utils/adt/numutils.c
M src/backend/utils/adt/regexp.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/adt/ruleutils.c
M src/backend/utils/adt/varchar.c
M src/backend/utils/adt/varlena.c
M src/backend/utils/cache/relcache.c
M src/backend/utils/cache/relmapper.c
M src/backend/utils/cache/syscache.c
M src/backend/utils/fmgr/fmgr.c
M src/backend/utils/hash/hashfn.c
M src/backend/utils/init/globals.c
M src/backend/utils/init/miscinit.c
M src/backend/utils/mb/mbutils.c
M src/backend/utils/misc/guc.c
M src/backend/utils/mmgr/dsa.c
M src/bin/initdb/initdb.c
M src/bin/pg_archivecleanup/pg_archivecleanup.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/pg_recvlogical.c
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_dump/common.c
M src/bin/pg_dump/compress_io.c
M src/bin/pg_dump/parallel.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_custom.c
M src/bin/pg_dump/pg_backup_db.c
M src/bin/pg_dump/pg_backup_directory.c
M src/bin/pg_dump/pg_backup_tar.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_dump/pg_restore.c
M src/bin/pg_rewind/filemap.c
M src/bin/pg_rewind/libpq_fetch.c
M src/bin/pg_rewind/parsexlog.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pg_upgrade/controldata.c
M src/bin/pg_upgrade/function.c
M src/bin/pg_waldump/pg_waldump.c
M src/bin/pgbench/pgbench.c
M src/bin/psql/command.c
M src/bin/psql/common.c
M src/bin/psql/copy.c
M src/bin/psql/crosstabview.c
M src/bin/psql/describe.c
M src/bin/psql/startup.c
M src/bin/psql/tab-complete.c
M src/bin/psql/variables.c
M src/common/d2s.c
M src/common/f2s.c
M src/common/file_utils.c
M src/common/logging.c
M src/common/pg_lzcompress.c
M src/common/rmtree.c
M src/include/access/amapi.h
M src/include/access/gistxlog.h
M src/include/access/hio.h
M src/include/access/relscan.h
M src/include/access/spgist_private.h
M src/include/access/spgxlog.h
M src/include/access/tableam.h
M src/include/access/tupdesc.h
M src/include/access/xlog.h
M src/include/access/xlog_internal.h
M src/include/catalog/dependency.h
M src/include/catalog/index.h
M src/include/catalog/pg_attrdef.h
M src/include/catalog/pg_default_acl.h
M src/include/catalog/pg_policy.h
M src/include/catalog/storage.h
M src/include/commands/defrem.h
M src/include/commands/trigger.h
M src/include/commands/vacuum.h
M src/include/common/file_utils.h
M src/include/common/logging.h
M src/include/executor/execParallel.h
M src/include/executor/executor.h
M src/include/executor/tuptable.h
M src/include/libpq/libpq-be.h
M src/include/miscadmin.h
M src/include/nodes/execnodes.h
M src/include/nodes/parsenodes.h
M src/include/nodes/plannodes.h
M src/include/parser/parse_node.h
M src/include/pgstat.h
M src/include/port.h
M src/include/replication/logical.h
M src/include/replication/reorderbuffer.h
M src/include/statistics/extended_stats_internal.h
M src/include/statistics/statistics.h
M src/include/storage/fd.h
M src/include/storage/md.h
M src/include/tcop/deparse_utility.h
M src/include/utils/datum.h
M src/interfaces/ecpg/ecpglib/cursor.c
M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/ecpglib/ecpglib_extern.h
M src/interfaces/ecpg/ecpglib/error.c
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/ecpglib/prepare.c
M src/interfaces/ecpg/include/ecpglib.h
M src/interfaces/ecpg/preproc/ecpg.c
M src/interfaces/ecpg/preproc/output.c
M src/interfaces/ecpg/preproc/preproc_extern.h
M src/interfaces/ecpg/preproc/type.h
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/libpq-fe.h
M src/interfaces/libpq/pqexpbuffer.c
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/plpgsql.h
M src/pl/plpython/plpy_exec.c
M src/pl/tcl/pltcl.c
M src/port/dlopen.c
M src/port/pg_bitutils.c
M src/port/strtof.c
M src/test/regress/pg_regress.c
M src/test/regress/regress.c
M src/tools/pgindent/typedefs.list
Convert ExecComputeStoredGenerated to use tuple slots
commit : 66a4bad83aaa6613a45a00a488c04427f9969fb4
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 15 May 2019 19:37:52 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 15 May 2019 19:37:52 +0200 This code was still using the old style of forming a heap tuple rather
than using tuple slots. This would be less efficient if a non-heap
access method was used. And using tuple slots is actually quite a bit
faster when using heap as well.
Also add some test cases for generated columns with null values and
with varlena values. This lack of coverage was discovered while
working on this patch.
Discussion: https://www.postgresql.org/message-id/flat/20190331025744.ugbsyks7czfcoksd%40alap3.anarazel.de M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql
Mention ANALYZE boolean options in documentation.
commit : 03de5187d50af67d154a47cf00899290dca13003
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 23 May 2019 01:18:16 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 23 May 2019 01:18:16 +0900 Commit 41b54ba78e allowed not only VACUUM but also ANALYZE options
to take a boolean argument. But it forgot to update the documentation
for ANALYZE. This commit adds the descriptions about those ANALYZE
boolean options into the documentation.
This patch also updates tab-completion for ANALYZE boolean options.
Reported-by: Kyotaro Horiguchi
Author: Fujii Masao
Reviewed-by: Masahiko Sawada, Michael Paquier
Discussion: https://postgr.es/m/CAHGQGwHTUt-kuwgiwe8f0AvTnB+ySqJWh95jvmh-qcoKW9YA9g@mail.gmail.com M doc/src/sgml/ref/analyze.sgml
M doc/src/sgml/release-12.sgml
M src/bin/psql/tab-complete.c
Fix O(N^2) performance issue in pg_publication_tables view.
commit : 166f69f769c83ef8759d905bf7f1a9aa1d97a340
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 11:46:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 11:46:57 -0400 The original coding of this view relied on a correlated IN sub-query.
Our planner is not very bright about correlated sub-queries, and even
if it were, there's no way for it to know that the output of
pg_get_publication_tables() is duplicate-free, making the de-duplicating
semantics of IN unnecessary. Hence, rewrite as a LATERAL sub-query.
This provides circa 100X speedup for me with a few hundred published
tables (the whole regression database), and things would degrade as
roughly O(published_relations * all_relations) beyond that.
Because the rules.out expected output changes, force a catversion bump.
Ordinarily we might not want to do that post-beta1; but we already know
we'll be doing a catversion bump before beta2 to fix pg_statistic_ext
issues, so it's pretty much free to fix it now instead of waiting for v13.
Per report and fix suggestion from PegoraroF10.
Discussion: https://postgr.es/m/1551385426763-0.post@n3.nabble.com M src/backend/catalog/system_views.sql
M src/include/catalog/catversion.h
M src/test/regress/expected/rules.out
docs: PG 12 release notes, support functions
commit : 728840fe13acff7b03a4b1a813eeb8900ce5e469
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 22 May 2019 11:22:13 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 22 May 2019 11:22:13 -0400 Move support function mention to the proper section, and reword.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/5121.1558472431@sss.pgh.pa.us M doc/src/sgml/release-12.sgml
doc: PG 12 relnotes, correct recovery_target* variable mention
commit : ba95a6933632410d103d6f17cd3bc1adf92a08f9
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 22 May 2019 10:54:40 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 22 May 2019 10:54:40 -0400 Clarify new restriction on recovery_target* variables.
Reported-by: Gaby Schilders
Discussion: reported via chat M doc/src/sgml/release-12.sgml
Add .gitignore entries for new ecpg test case.
commit : 4a657ab260499381c645673ca1c3255adc0b2ace
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 10:42:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 10:42:24 -0400 Oversight in commit a1dc6ab465986a62b308dd1bb8da316b5ed9685a. M src/interfaces/ecpg/test/sql/.gitignore
In transam.h, don’t expose static inline functions to frontend code.
commit : 4fbf809e13c3ba09c4f03d148cb58767e56f67f1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 10:38:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 10:38:21 -0400 That leads to unsatisfied external references if the C compiler fails
to elide unused static functions. Apparently, we have no buildfarm
members building HEAD that have that issue ... but such compilers still
exist in the wild. Need to do something about that.
In passing, fix Berkeley-era typo in comment.
Discussion: https://postgr.es/m/27054.1558533367@sss.pgh.pa.us M src/include/access/transam.h
Fix ordering of GRANT commands in pg_dump for database creation
commit : b8c6014a65ee0819e8fe4c7536f72da0df5d8e46
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 22 May 2019 14:48:00 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 22 May 2019 14:48:00 +0900 This uses a method similar to 68a7c24f, which guarantees that GRANT
commands using the WITH GRANT OPTION are dumped in a way so as cascading
dependencies are respected. As databases do not have support for
initial privileges via pg_init_privs, we need to repeat again the same
ACL reordering method.
ACL for databases have been moved from pg_dumpall to pg_dump in v11, so
this impacts pg_dump for v11 and above, and pg_dumpall for v9.6 and
v10.
Discussion: https://postgr.es/m/15788-4e18847520ebcc75@postgresql.org
Author: Nathan Bossart
Reviewed-by: Haribabu Kommi
Backpatch-through: 9.6 M src/bin/pg_dump/pg_dump.c
Un-break pg_upgrade regression test.
commit : 5eb4a51cb15166392ca3ede6ec58f8f1f820ef53
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 23:51:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 23:51:19 -0400 Commit 5af2e976d removed a bit too much from the test.sh invocation.
Per buildfarm. M src/bin/pg_upgrade/Makefile
Implement PREPARE AS statement for ECPG.
commit : a1dc6ab465986a62b308dd1bb8da316b5ed9685a
author : Michael Meskes <meskes@postgresql.org>
date : Wed, 22 May 2019 04:58:29 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Wed, 22 May 2019 04:58:29 +0200 Besides implementing the new statement this change fix some issues with the
parsing of PREPARE and EXECUTE statements. The different forms of these
statements are now all handled in a ujnified way.
Author: Matsumura-san <matsumura.ryo@jp.fujitsu.com> M src/interfaces/ecpg/ecpglib/ecpglib_extern.h
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/ecpglib/prepare.c
M src/interfaces/ecpg/include/ecpgtype.h
M src/interfaces/ecpg/preproc/check_rules.pl
M src/interfaces/ecpg/preproc/ecpg.addons
M src/interfaces/ecpg/preproc/ecpg.header
M src/interfaces/ecpg/preproc/output.c
M src/interfaces/ecpg/preproc/parse.pl
M src/interfaces/ecpg/preproc/type.h
M src/interfaces/ecpg/test/ecpg_schedule
A src/interfaces/ecpg/test/expected/sql-prepareas.c
A src/interfaces/ecpg/test/expected/sql-prepareas.stderr
A src/interfaces/ecpg/test/expected/sql-prepareas.stdout
M src/interfaces/ecpg/test/sql/Makefile
A src/interfaces/ecpg/test/sql/prepareas.pgc
pg_upgrade: Avoid check target accidentally breaking make’s –output-sync.
commit : 5af2e976d72aa345337596cc986237c57e1146b2
author : Andres Freund <andres@anarazel.de>
date : Tue, 21 May 2019 15:03:27 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 21 May 2019 15:03:27 -0700 When $(MAKE) is present in a rule, make assumes that target is a
submake, and it doesn't need to buffer its output. But in this case
it's a shell script that needs buffered output. Avoid that heuristic,
by referring to $(MAKE) via an indirection.
Discussion: https://postgr.es/m/20190521004717.qsktdsugj3shagco@alap3.anarazel.de M src/bin/pg_upgrade/Makefile
pg_upgrade: Don’t use separate installation for test.
commit : 7005389b2ad17258bc3aa0a2427c4eb77fed1d09
author : Andres Freund <andres@anarazel.de>
date : Tue, 21 May 2019 14:56:29 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 21 May 2019 14:56:29 -0700 For pg_upgrade's test we (unless prevented by the caller via via
NO_TEMP_INSTALL) built a separate installation. That causes an
unnecessary slowdown after the infrastructure introduced by
dcae5faccab (and unnecessarily duplicates code).
Author: Andres Freund
Reviewed-By: Tom Lane
Discussion:
https://postgr.es/m/20190521191918.z7kwnrlj45mk2k67@alap3.anarazel.de
https://postgr.es/m/20190521195209.qfzwfxvymguuwlu5@alap3.anarazel.de M src/bin/pg_upgrade/Makefile
M src/bin/pg_upgrade/test.sh
docs: PG 12 relnote adjustments based on feedback from Tom Lane
commit : 8e719d33fd253fc378871ba4dbf2de41fd2ba462
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:45:48 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:45:48 -0400 Discussion: https://postgr.es/m/22793.1558399695@sss.pgh.pa.us M doc/src/sgml/release-12.sgml
docs: adjust RECORD PG 12 relnote item
commit : 3468a04a3e498bab755909505e8f7b6023bea493
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:35:43 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:35:43 -0400 Discussion: https://postgr.es/m/15486.1558393010@sss.pgh.pa.us M doc/src/sgml/release-12.sgml
doc: adjust PG 12 relnotes item on float digit adjustment
commit : b84a801d6a6737e6d84326b77d98b498402ecad0
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:31:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:31:02 -0400 Discussion: https://postgr.es/m/87y330d8ty.fsf@news-spur.riddles.org.uk M doc/src/sgml/release-12.sgml
doc: fix markup for PG 12 rel notes
commit : 0fca8285ea533fa669a372c91fdb42265dcf7435
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:19:43 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:19:43 -0400 M doc/src/sgml/release-12.sgml
doc: adjustments for PG 12 release notes
commit : 32fe2e3194c7198ca4afdb6bea4ffa12466612b1
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:14:33 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:14:33 -0400 Mostly commit messages, attribution, and text, all suggested by Andres
Freund.
Discussion: https://postgr.es/m/20190520221719.pqgld3krjc2docr5@alap3.anarazel.de M doc/src/sgml/release-12.sgml
Make pg_upgrade’s test.sh less chatty.
commit : eb9812f272db8e93416831e5254569b76edf8264
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 13:11:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 13:11:57 -0400 The use of "set -x" to echo a subset of the test's commands might've
been a good idea during development of this test, but it's been stable
for long enough now that the extra output isn't very useful. Also
our project expectations have been trending towards less output in
non-error cases; the fact that "set -x" produces output on stderr
is particularly annoying from that standpoint. So get rid of it.
Also, pass "-A trust" to initdb explicitly so that it won't issue
a warning about "trust" being an insecure default. This matches
what the TAP tests have done for a long time, and again gets rid
of some noise on stderr.
Discussion: https://postgr.es/m/21766.1558397960@sss.pgh.pa.us M src/bin/pg_upgrade/test.sh
Insert temporary debugging output in regression tests.
commit : f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 12:23:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 12:23:16 -0400 We're seeing occasional instability in the plans generated for
parallel queries on the "a_star" table hierarchy. This suggests
that something is changing the planner's stats for those tables,
but that should not be happening within a regression test run.
To try to gather some information about what's happening, insert
additional queries to check the basic page/tuple counts for these
tables, as well as whether any vacuums or analyzes have happened
on them. (We expect that only the database-wide VACUUM in
sanity_check.sql will have touched them.)
I added the probes not only in select_parallel.sql itself, but
also in stats.sql, bearing in mind that the stats collector's
lag may prevent the initial query from reporting current truth.
If any extra vacuum/analyze has happened, the recheck in stats.sql
definitely ought to see it.
This commit can be reverted once we figure out what's going on.
Per suggestion from David Rowley, though I changed the queries around.
Discussion: https://postgr.es/m/CA+hUKG+0CxrKRWRMf5ymN3gm+BECHna2B-q1w8onKBep4HasUw@mail.gmail.com M src/test/regress/expected/select_parallel.out
M src/test/regress/expected/stats.out
M src/test/regress/sql/select_parallel.sql
M src/test/regress/sql/stats.sql
tableam: Move heap-specific logic from needs_toast_table below tableam.
commit : 1171d7d58545f26a402f76a05936d572bf29d53b
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 21 May 2019 11:57:13 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 21 May 2019 11:57:13 -0400 This allows table AMs to completely suppress TOAST table creation, or
to modify the conditions under which they are created.
Patch by me. Reviewed by Andres Freund.
Discussion: http://postgr.es/m/CA+Tgmoa4O2n=yphqD2pERUnYmUO84bH1SqMsA-nSxBGsZ7gWfA@mail.gmail.com M src/backend/access/heap/heapam_handler.c
M src/backend/catalog/toasting.c
M src/include/access/tableam.h
Doc: improve description of regexp character classes.
commit : cf92226e9f7f985a678287167b954a831a3b660c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 May 2019 18:39:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 May 2019 18:39:53 -0400 Define the meanings of the POSIX-spec character classes in line,
rather than referring to the ctype(3) man page. That man page
doesn't even exist on many modern systems, and if it does exist
it probably says the wrong things about non-ASCII characters.
Also document our non-POSIX-spec "ascii" character class.
Also, point out here that this behavior is controlled by collation or
LC_CTYPE, since the existing text explaining that is pretty far away.
Per gripe from Geert Lobbestael. Given the lack of prior complaints,
I'm not excited about back-patching this.
Discussion: https://postgr.es/m/155837022049.1359.2948065118562813468@wrigleys.postgresql.org M doc/src/sgml/func.sgml
Stamp 12beta1.
commit : a240570b1e3802d1e82da08a9d72abeade370249
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 May 2019 16:37:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 May 2019 16:37:22 -0400 M configure
M configure.in
M src/include/pg_config.h.win32
Fix regression tests broken in fc7c281f87467.
commit : 47a14c99e4715dde7f570d050e1ddb6d21278bf8
author : Andres Freund <andres@anarazel.de>
date : Mon, 20 May 2019 09:36:06 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 20 May 2019 09:36:06 -0700 This shouldn't have been committed without even running the tests (nor
were the tests added that were suggested). I'm fixing up the results
to get the buildfarm back to green, it's quite possible we'll want to
revert this later. M src/test/regress/expected/vacuum.out
Fix comment for issue_xlog_fsync().
commit : b8e2170e40a151eb94079ce9cd791a712ed95342
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 21 May 2019 00:44:00 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 21 May 2019 00:44:00 +0900 "segno" is the argument for the function, not "log" and "seg".
Author: Antonin Houska
Discussion: https://postgr.es/m/11863.1558361020@spoje.net M src/backend/access/transam/xlog.c
Make VACUUM accept 1 and 0 as a boolean value.
commit : fc7c281f87467c1ff24fd72e0cc313dd6a71873f
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 21 May 2019 00:22:06 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 21 May 2019 00:22:06 +0900 Commit 41b54ba78e allowed existing VACUUM options to take a boolean
argument. It's documented that valid boolean values that VACUUM can
accept are true, false, on, off, 1, and 0. But previously the parser
failed to accept 1 and 0 as a boolean value in VACUUM syntax because
of a lack of NumericOnly clause for vac_analyze_option_arg in gram.y.
This commit adds such NumericOnly clause so that VACUUM options
can take also 1 and 0 as a boolean value.
Discussion: https://postgr.es/m/CAHGQGwGYg82A8UCQxZe7Zn9MnyUBGdyB=1CNpKF3jBny+RbyfA@mail.gmail.com M src/backend/parser/gram.y
Translation updates
commit : 3c439a58df83ae51f650cfae9878df1f9b70c4b8
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 20 May 2019 16:00:53 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 20 May 2019 16:00:53 +0200 Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: a20bf6b8a5b4e32450967055eb5b07cee4704edd M src/backend/nls.mk
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/ja.po
M src/backend/po/ko.po
M src/backend/po/ru.po
M src/backend/po/sv.po
A src/backend/po/tr.po
M src/bin/initdb/po/de.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/sv.po
M src/bin/pg_archivecleanup/po/de.po
M src/bin/pg_archivecleanup/po/es.po
M src/bin/pg_archivecleanup/po/fr.po
M src/bin/pg_archivecleanup/po/sv.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_checksums/nls.mk
A src/bin/pg_checksums/po/es.po
A src/bin/pg_checksums/po/sv.po
M src/bin/pg_config/po/cs.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/fr.po
M src/bin/pg_config/po/ja.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_config/po/tr.po
M src/bin/pg_controldata/po/cs.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_controldata/po/it.po
M src/bin/pg_controldata/po/ja.po
M src/bin/pg_controldata/po/ko.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_controldata/po/sv.po
M src/bin/pg_controldata/po/tr.po
M src/bin/pg_ctl/po/cs.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_ctl/po/he.po
M src/bin/pg_ctl/po/it.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_ctl/po/ko.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_ctl/po/sv.po
M src/bin/pg_ctl/po/tr.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_resetwal/po/de.po
M src/bin/pg_resetwal/po/es.po
M src/bin/pg_resetwal/po/sv.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/nls.mk
A src/bin/pg_test_fsync/po/cs.po
M src/bin/pg_test_fsync/po/es.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_test_fsync/po/tr.po
M src/bin/pg_test_timing/nls.mk
A src/bin/pg_test_timing/po/cs.po
M src/bin/pg_test_timing/po/es.po
M src/bin/pg_upgrade/nls.mk
A src/bin/pg_upgrade/po/cs.po
M src/bin/pg_upgrade/po/de.po
A src/bin/pg_upgrade/po/es.po
M src/bin/pg_upgrade/po/fr.po
M src/bin/pg_upgrade/po/ja.po
M src/bin/pg_upgrade/po/ko.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_upgrade/po/tr.po
M src/bin/pg_waldump/po/de.po
M src/bin/pg_waldump/po/es.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_waldump/po/sv.po
M src/bin/psql/nls.mk
M src/bin/psql/po/cs.po
M src/bin/psql/po/de.po
M src/bin/psql/po/es.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
A src/bin/psql/po/tr.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/sv.po
M src/interfaces/ecpg/ecpglib/po/cs.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/fr.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/ecpglib/po/sv.po
M src/interfaces/ecpg/preproc/po/cs.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/ecpg/preproc/po/it.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/ecpg/preproc/po/ko.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/ecpg/preproc/po/sv.po
M src/interfaces/ecpg/preproc/po/tr.po
M src/interfaces/libpq/po/cs.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/he.po
M src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ko.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/sv.po
M src/interfaces/libpq/po/tr.po
M src/pl/plperl/po/cs.po
M src/pl/plperl/po/de.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/fr.po
M src/pl/plperl/po/it.po
M src/pl/plperl/po/ru.po
M src/pl/plperl/po/sv.po
M src/pl/plpgsql/src/po/cs.po
M src/pl/plpgsql/src/po/de.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/plpgsql/src/po/it.po
M src/pl/plpgsql/src/po/ja.po
M src/pl/plpgsql/src/po/ko.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpgsql/src/po/tr.po
M src/pl/plpython/po/cs.po
M src/pl/plpython/po/de.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/it.po
M src/pl/plpython/po/ja.po
M src/pl/plpython/po/ko.po
M src/pl/plpython/po/ru.po
M src/pl/plpython/po/sv.po
M src/pl/plpython/po/tr.po
M src/pl/plpython/po/vi.po
M src/pl/tcl/po/cs.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/fr.po
M src/pl/tcl/po/ru.po
M src/pl/tcl/po/sv.po
Remove bug.template file
commit : 8bbb8166b63eeebd0cb618ddcf7dcaf8c4ba66f4
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 20 May 2019 08:33:31 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 20 May 2019 08:33:31 +0200 It's outdated and not really in use anymore.
Discussion: https://www.postgresql.org/message-id/flat/cf7ed2b1-1ebe-83cf-e05e-d5943f67af2d%402ndquadrant.com M .gitattributes
D doc/bug.template
M src/tools/version_stamp.pl
Remove outdated comment in copy.c.
commit : fb504c5e4b5ce71e703006375ee2f5e4b57d89c9
author : Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 20:47:54 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 20:47:54 -0700 M src/backend/commands/copy.c
Minimally fix partial aggregation for aggregates that don’t have one argument.
commit : 2657283256f1cab53d09d2c7db1ce9b7065193a0
author : Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 18:01:06 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 18:01:06 -0700 For partial aggregation combine steps,
AggStatePerTrans->numTransInputs was set to the transition function's
number of inputs, rather than the combine function's number of
inputs (always 1).
That lead to partial aggregates with strict combine functions to
wrongly check for NOT NULL input as required by strictness. When the
aggregate wasn't exactly passed one argument, the strictness check was
either omitted (in the 0 args case) or too many arguments were
checked. In the latter case we'd read beyond the end of
FunctionCallInfoData->args (only in master).
AggStatePerTrans->numTransInputs actually has been wrong since since
9.6, where partial aggregates were added. But it turns out to not be
an active problem in 9.6 and 10, because numTransInputs wasn't used at
all for combine functions: Before c253b722f6 there simply was no NULL
check for the input to strict trans functions, and after that the
check was simply hardcoded for the right offset in fcinfo, as it's
done by code specific to combine functions.
In bf6c614a2f2 (11) the strictness check was generalized, with common
code doing the strictness checks for both plain and combine transition
functions, based on numTransInputs. For combine functions this lead to
not emitting an expression step to check for strict input in the 0
arguments case, and in the > 1 arguments case, we'd check too many
arguments.Due to the fact that the relevant fcinfo->isnull[2..] was
always zero-initialized (more or less by accident, by being part of
the AggStatePerTrans struct, which is palloc0'ed), there was no
observable damage in the latter case before a9c35cf85ca1f, we just
checked too many array elements.
Due to the changes in a9c35cf85ca1f, > 1 argument bug became visible,
because these days fcinfo is a) dynamically allocated without being
zeroed b) exactly the length required for the number of specified
arguments (hardcoded to 2 in this case).
This commit only contains a fairly minimal fix, setting numTransInputs
to a hardcoded 1 when building a pertrans for a combine function. It
seems likely that we'll want to clean this up further (e.g. the
arguments build_pertrans_for_aggref() aren't particularly meaningful
for combine functions). But the wrap date for 12 beta1 is coming up
fast, so it seems good to have a minimal fix in place.
Backpatch to 11. While AggStatePerTrans->numTransInputs was set
wrongly before that, the value was not used for combine functions.
Reported-By: Rajkumar Raghuwanshi
Diagnosed-By: Kyotaro Horiguchi, Jeevan Chalke, Andres Freund, David Rowley
Author: David Rowley, Kyotaro Horiguchi, Andres Freund
Discussion: https://postgr.es/m/CAKcux6=uZEyWyLw0N7HtR9OBc-sWEFeByEZC7t-KDf15FKxVew@mail.gmail.com M src/backend/executor/nodeAgg.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Fix some grammar in documentation of spgist and pgbench
commit : 03310dbea9746439e9f0fdedce0fa298b8c4cc76
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 20 May 2019 09:47:19 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 20 May 2019 09:47:19 +0900 Discussion: https://postgr.es/m/92961161-9b49-e42f-0a72-d5d47e0ed4de@postgrespro.ru
Author: Liudmila Mantrova
Reviewed-by: Jonathan Katz, Tom Lane, Michael Paquier
Backpatch-through: 9.4 M doc/src/sgml/ref/pgbench.sgml
M doc/src/sgml/spgist.sgml
Fix and improve SnapshotType comments.
commit : 78d6a9cbd3438969ac87b9f1aaf0f07226636ed7
author : Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 16:17:18 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 16:17:18 -0700 The comment for SNAPSHOT_SELF was unfortunately explaining
SNAPSHOT_DIRTY, as reported by Sergei. Also expand a few comments, and
include a few more comments from heapam_visibility.c, so they're in an
AM independent place.
Reported-By: Sergei Kornilov
Author: Andres Freund
Discussion: https://postgr.es/m/9152241558192351@sas1-d856b3d759c7.qloud-c.yandex.net M src/include/utils/snapshot.h
Revert “In the pg_upgrade test suite, don’t write to src/test/regress.”
commit : ae35e1c9d74afc3b1e7572ad60781946fdf71e95
author : Noah Misch <noah@leadboat.com>
date : Sun, 19 May 2019 15:24:42 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 19 May 2019 15:24:42 -0700 This reverts commit bd1592e8570282b1650af6b8eede0016496daecd. It had
multiple defects.
Discussion: https://postgr.es/m/12717.1558304356@sss.pgh.pa.us M src/bin/pg_upgrade/test.sh
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
M src/test/regress/output/largeobject_1.source
M src/tools/msvc/vcregress.pl
Don’t to predicate lock for analyze scans, refactor scan option passing.
commit : c3b23ae457ddc8b7bfacb3c0569278615a2df2cd
author : Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 15:10:28 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 15:10:28 -0700 Before this commit, when ANALYZE was run on a table and serializable
was used (either by virtue of an explicit BEGIN TRANSACTION ISOLATION
LEVEL SERIALIZABLE, or default_transaction_isolation being set to
serializable) a null pointer dereference lead to a crash.
The analyze scan doesn't need a snapshot (nor predicate locking), but
before this commit a scan only contained information about being a
bitmap or sample scan.
Refactor the option passing to the scan_begin callback to use a
bitmask instead. Alternatively we could have added a new boolean
parameter, but that seems harder to read. Even before this issue
various people (Heikki, Tom, Robert) suggested doing so.
These changes don't change the scan APIs outside of tableam. The flags
argument could be exposed, it's not necessary to fix this
problem. Also the wrapper table_beginscan* functions encapsulate most
of that complexity.
After these changes fixing the bug is trivial, just don't acquire
predicate lock for analyze style scans. That was already done for
bitmap heap scans. Add an assert that a snapshot is passed when
acquiring the predicate lock, so this kind of bug doesn't require
running with serializable.
Also add a comment about sample scans currently requiring predicate
locking the entire relation, that previously wasn't remarked upon.
Reported-By: Joe Wildish
Author: Andres Freund
Discussion:
https://postgr.es/m/4EA80A20-E9BF-49F1-9F01-5B66CAB21453@elusive.cx
https://postgr.es/m/20190411164947.nkii4gaeilt4bui7@alap3.anarazel.de
https://postgr.es/m/20190518203102.g7peu2fianukjuxm@alap3.anarazel.de M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/table/tableam.c
M src/include/access/heapam.h
M src/include/access/relscan.h
M src/include/access/tableam.h
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
In the pg_upgrade test suite, don’t write to src/test/regress.
commit : bd1592e8570282b1650af6b8eede0016496daecd
author : Noah Misch <noah@leadboat.com>
date : Sun, 19 May 2019 14:36:44 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 19 May 2019 14:36:44 -0700 When this suite runs installcheck, redirect file creations from
src/test/regress to src/bin/pg_upgrade/tmp_check/regress. This closes a
race condition in "make -j check-world". If the pg_upgrade suite wrote
to a given src/test/regress/results file in parallel with the regular
src/test/regress invocation writing it, a test failed spuriously. Even
without parallelism, in "make -k check-world", the suite finishing
second overwrote the other's regression.diffs. This revealed test
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.
Buildfarm client REL_10, released forty-five days ago, supports saving
regression.diffs from its new location. When an older client reports a
pg_upgradeCheck failure, it will no longer include regression.diffs.
Back-patch to 9.5, where pg_upgrade moved to src/bin.
Reviewed by Andrew Dunstan.
Discussion: https://postgr.es/m/20181224034411.GA3224776@rfd.leadboat.com M src/bin/pg_upgrade/test.sh
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
M src/test/regress/output/largeobject_1.source
M src/tools/msvc/vcregress.pl
Improve logrotate test so that it meaningfully exercises syslogger.
commit : 9d5c22d28f8c161aa729d841aeec936c646044d4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 May 2019 13:55:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 May 2019 13:55:39 -0400 Discussion of bug #15804 reveals that this test didn't really prove
that the syslogger child process ever launched successfully, much
less did anything. It was only checking that the expected log file
gets created, and that's done in the postmaster. Moreover, the
test assumed it could rename the log file, which is likely to fail
on Windows (cf. commit d611175e5).
Instead, use the default log file name pattern, which should result
in a new file name being chosen after 1 second, and verify that
rotation has occurred by checking for a new file name. Also add code
to test that messages actually do propagate through the syslogger.
In theory this version of the test should work on Windows, so
revert d611175e5.
Discussion: https://postgr.es/m/15804-3721117bf40fb654@postgresql.org M src/bin/pg_ctl/t/004_logrotate.pl
Revert “postmaster: Start syslogger earlier”.
commit : 833451552925d0175e1e15128e411ddef9a36996
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 May 2019 11:14:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 May 2019 11:14:23 -0400 This commit reverts 57431a911d3a650451d198846ad3194900666152.
While that's still a good idea in the abstract, we found out
that there are multiple crasher bugs in it on Windows builds,
making the logging_collector option unusable on Windows.
There's no time left to fix these issues before 12beta1,
so revert the patch to allow Windows beta testing to proceed.
We'll try again at some future date.
Per bug #15804 from Yulian Khodorkovskiy and additional
investigation by Michael Paquier.
Discussion: https://postgr.es/m/15804-3721117bf40fb654@postgresql.org M src/backend/postmaster/postmaster.c
Fix declarations of couple jsonpath functions
commit : da24961e9e1d887111d17cc2dcece2e3946ca5a6
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 19 May 2019 07:45:42 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 19 May 2019 07:45:42 +0300 Make jsonb_path_query_array() and jsonb_path_query_first() use
PG_FUNCTION_ARGS macro instead of its expansion. M src/backend/utils/adt/jsonpath_exec.c
Improve documentation for array subscription in jsonpath
commit : 87bcc02f4f739d76703feee0ff8346b98fa9b907
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 17 May 2019 05:47:53 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 17 May 2019 05:47:53 +0300 Usage of expressions and multiple ranges in jsonpath array subscription was
undocumented. This commit adds lacking documentation. M doc/src/sgml/json.sgml
Document jsonpath .** accessor with nesting level filter
commit : e0e3dad770d3eefc4ee6cd562d9c25b61c263a6e
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 17 May 2019 05:16:31 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 17 May 2019 05:16:31 +0300 It appears that some variants of .** jsonpath accessor are undocumented. In
particular undocumented variants are:
.**{level}
.**{lower_level to upper_level}
.**{lower_level to last}
This commit adds missing documentation for them. M doc/src/sgml/json.sgml
ANSI-ify a few straggler K&R-style function definitions.
commit : da71f98efba9aed493a178aa29f25dbca7407eaf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 20:16:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 20:16:50 -0400 We still had a couple of these left in ancient src/port/ files.
Convert them to modern style in preparation for switching to
a version of pg_bsd_indent that doesn't cope well with K&R style.
Discussion: https://postgr.es/m/16886.1558104483@sss.pgh.pa.us M src/port/crypt.c
M src/port/isinf.c
Make BufFileCreateTemp() ensure that temp tablespaces are set up.
commit : 93f03dad824f14f40519597e5e4a8fe7b6df858e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 13:51:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 13:51:16 -0400 If PrepareTempTablespaces() has never been called in the current
transaction, OpenTemporaryFile() will fall back to using the default
tablespace, which is a bug if the user wanted temp files placed elsewhere.
gistInitBuildBuffers() appears to have this disease already, and it
seems like an easy trap for future coders to fall into.
We discussed other ways to close this gap, but none of them are prettier
or more reliable than just having BufFileCreateTemp do it. In particular,
having fd.c do this creates layering issues that we could do without.
Per suggestion from Melanie Plageman. Arguably this is a bug fix, but
nobody seems very excited about back-patching, so change in HEAD only.
Discussion: https://postgr.es/m/CAAKRu_YwzjuGAmmaw4-8XO=OVFGR1QhY_Pq-t3wjb9ribBJb_Q@mail.gmail.com M src/backend/storage/file/buffile.c
docs: tighten up PG 12 release note item on 1k partitions
commit : b12db9ff5f09dc60dc05d0e208a5b28728970e55
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 18 May 2019 09:23:29 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 18 May 2019 09:23:29 -0400 M doc/src/sgml/release-12.sgml
“A void function may not return a value”.
commit : d307954a7d88ed45655d9206bbe1aefc280c09c7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 00:40:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 00:40:39 -0400 Per buildfarm. M src/backend/access/table/tableam.c
tableam: Avoid relying on relation size to determine validity of tids.
commit : 147e3722f7e531f15ba389a4d518efe8cd0bd736
author : Andres Freund <andres@anarazel.de>
date : Fri, 17 May 2019 18:52:01 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 17 May 2019 18:52:01 -0700 Instead add a tableam callback to do so. To avoid adding per
validation overhead, pass a scan to tuple_tid_valid. In heap's case
we'd otherwise incurred a RelationGetNumberOfBlocks() call for each
tid - which'd have added noticable overhead to nodeTidscan.c.
Author: Andres Freund
Reviewed-By: Ashwin Agrawal
Discussion: https://postgr.es/m/20190515185447.gno2jtqxyktylyvs@alap3.anarazel.de M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/table/tableam.c
M src/backend/executor/nodeTidscan.c
M src/backend/utils/adt/tid.c
M src/include/access/heapam.h
M src/include/access/tableam.h
tableam: Don’t assume that every AM uses md.c style storage.
commit : 7f44ede5941499c4cee13b812dd93335f4005095
author : Andres Freund <andres@anarazel.de>
date : Fri, 17 May 2019 18:06:18 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 17 May 2019 18:06:18 -0700 Previously various parts of the code routed size requests through
RelationGetNumberOfBlocks[InFork]. That works if md.c is used by the
AM, but not otherwise.
Add a tableam callback to return the size of the table. As not every
AM will use postgres' BLCKSZ, have it return bytes, and have
RelationGetNumberOfBlocksInFork() round the byte size up into blocks.
To allow code outside of the AM to determine the actual relation size
map InvalidForkNumber the total size of a relation, as not every AM
might just need the postgres defined forks.
A few users of RelationGetNumberOfBlocks() ought to be converted away
from that. One case, the use of it to determine whether a tid is
valid, will be fixed in a follow up commit. Others will have to wait
for v13.
Author: Andres Freund
Discussion: https://postgr.es/m/20190423225201.3bbv6tbqzkb5w7cw@alap3.anarazel.de M src/backend/access/heap/heapam_handler.c
M src/backend/access/table/tableamapi.c
M src/backend/storage/buffer/bufmgr.c
M src/include/access/tableam.h
Restructure creation of run-time pruning steps.
commit : 6630ccad7a25cad32e2d1a6833fb971602cb67fe
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 May 2019 19:44:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 May 2019 19:44:19 -0400 Previously, gen_partprune_steps() always built executor pruning steps
using all suitable clauses, including those containing PARAM_EXEC
Params. This meant that the pruning steps were only completely safe
for executor run-time (scan start) pruning. To prune at executor
startup, we had to ignore the steps involving exec Params. But this
doesn't really work in general, since there may be logic changes
needed as well --- for example, pruning according to the last operator's
btree strategy is the wrong thing if we're not applying that operator.
The rules embodied in gen_partprune_steps() and its minions are
sufficiently complicated that tracking their incremental effects in
other logic seems quite impractical.
Short of a complete redesign, the only safe fix seems to be to run
gen_partprune_steps() twice, once to create executor startup pruning
steps and then again for run-time pruning steps. We can save a few
cycles however by noting during the first scan whether we rejected
any clauses because they involved exec Params --- if not, we don't
need to do the second scan.
In support of this, refactor the internal APIs in partprune.c to make
more use of passing information in the GeneratePruningStepsContext
struct, rather than as separate arguments.
This is, I hope, the last piece of our response to a bug report from
Alan Jackson. Back-patch to v11 where this code came in.
Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com M src/backend/executor/execPartition.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/partitioning/partprune.c
M src/include/executor/execPartition.h
M src/include/nodes/plannodes.h
M src/include/partitioning/partprune.h
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
docs: split out sort-skip partition item in PG 12 release notes
commit : 05685897f07e7ae5684f0247157faad1f782f889
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 17 May 2019 11:31:49 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 17 May 2019 11:31:49 -0400 Discussion: https://postgr.es/m/0cf10a27-c6a0-de4a-cd20-ab7493ea7422@lab.ntt.co.jp M doc/src/sgml/release-12.sgml
Fix regression test outputs
commit : 6ba500cae6f57acf8f392d9e1671640f7c9d43b3
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 17 May 2019 09:40:02 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 17 May 2019 09:40:02 +0900 75445c1 has caused various failures in tests across the tree after
updating some error messages, so fix the newly-expected output.
Author: Michael Paquier
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/8332.1558048838@sss.pgh.pa.us M contrib/citext/expected/citext.out
M contrib/citext/expected/citext_1.out
M src/test/regress/expected/copy2.out
M src/test/regress/expected/create_table.out
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/expected/jsonpath.out
M src/test/regress/expected/publication.out
M src/test/regress/expected/regex.out
M src/test/regress/expected/strings.out
M src/test/regress/expected/subscription.out
M src/test/regress/output/copy.source
Fix typos in documentatoin of GSSAPI encryption
commit : 41998f90ce66425ca6071ac5e170a19bb1498414
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 17 May 2019 08:22:28 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 17 May 2019 08:22:28 +0900 Author: Daniel Gustafsson
Discussion: https://postgr.es/m/5520EDD8-7AC7-4307-8171-400DD1D84FDC@yesql.se M doc/src/sgml/protocol.sgml
M doc/src/sgml/runtime.sgml
More message style fixes
commit : 75445c1515fffa581585f1b72e5b5314c1c395ce
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 16 May 2019 18:50:56 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 16 May 2019 18:50:56 -0400 Discussion: https://postgr.es/m/20190515183005.GA26486@alvherre.pgsql M src/backend/commands/copy.c
M src/backend/commands/publicationcmds.c
M src/backend/commands/subscriptioncmds.c
M src/backend/commands/tablecmds.c
M src/backend/parser/analyze.c
M src/backend/postmaster/postmaster.c
M src/backend/replication/walsender.c
M src/backend/utils/adt/jsonpath.c
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/adt/jsonpath_scan.l
M src/backend/utils/adt/pg_locale.c
M src/backend/utils/adt/regexp.c
Remove extra nbtree half-dead internal page check.
commit : 3f58cc6dd8fc821992da7ed8099d283b014fc2dc
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 16 May 2019 15:11:58 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 16 May 2019 15:11:58 -0700 It's not safe for nbtree VACUUM to attempt to delete a target page whose
right sibling is already half-dead, since that would fail the
cross-check when VACUUM attempts to re-find a downlink to the right
sibling in the parent page. Logic to prevent this from happening was
added by commit 8da31837803, which addressed a bug in the overhaul of
page deletion that went into PostgreSQL 9.4 (commit efada2b8e92).
VACUUM was made to check the right sibling page, and back off when it
happened to be half-dead already.
However, it is only truly necessary to do the right sibling check on the
leaf level, since that transitively determines if the deletion target's
parent's right sibling page is itself undergoing deletion. Remove the
internal page level check, and add a comment explaining why the leaf
level check alone suffices.
The extra check is also unnecessary due to the fact that internal pages
that are marked half-dead are generally considered corrupt. Commit
efada2b8e92 established the principle that there should never be
half-dead internal pages (internal pages pending deletion are possible,
but that status is never directly represented in the internal page).
VACUUM will complain about corruption when it encounters half-dead
internal pages, so VACUUM is bound to raise an error one way or another
when an nbtree index has a half-dead internal page (contrib/amcheck will
also report that the page is corrupt).
It's possible that a pg_upgrade'd 9.3 database will still have half-dead
internal pages, so it may seem like there is an argument for leaving the
check in place to reliably get a cleaner error message that advises the
user to REINDEX. However, leaf pages are also deleted in the first
phase of deletion prior to PostgreSQL 9.4, so I believe we won't even
attempt to re-find the parent page anyway (we won't have the fully
deleted leaf page as the right sibling of our target page, so we won't
even try to find a downlink for it).
Discussion: https://postgr.es/m/CAH2-Wzm_ntmqJjWLRyKzimFmFvk+BnVAvUpaA4s1h9Ja58woaQ@mail.gmail.com M src/backend/access/nbtree/README
M src/backend/access/nbtree/nbtpage.c
Fix bogus logic for combining range-partitioned columns during pruning.
commit : 3922f10646fc79264228ea3f6a7343cc3f8f528a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 May 2019 16:25:43 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 May 2019 16:25:43 -0400 gen_prune_steps_from_opexps's notion of how to do this was overly
complicated and underly correct.
Per discussion of a report from Alan Jackson (though this fixes only one
aspect of that problem). Back-patch to v11 where this code came in.
Amit Langote
Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
Fix partition pruning to treat stable comparison operators properly.
commit : 4b1fcb43d070ba8b34ea01d5a657630d76e4b33f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 May 2019 11:58:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 May 2019 11:58:21 -0400 Cross-type comparison operators in a btree or hash opclass might be
only stable not immutable (this is true of timestamp vs. timestamptz
for example). partprune.c ignored this possibility and would perform
plan-time pruning with them anyway, possibly leading to wrong answers
if the environment changed between planning and execution.
To fix, teach gen_partprune_steps() to do things differently when
creating plan-time pruning steps vs. run-time pruning steps.
analyze_partkey_exprs() also needs an extra check, which is rather
annoying but now is not the time to restructure things enough to
avoid that.
While at it, simplify the logic for the plan-time case a little
by insisting that the comparison value be a Const and nothing else.
This relies on the assumption that eval_const_expressions will have
reduced any immutable expression to a Const; which is not quite
100% true, but certainly any case that comes up often enough to be
interesting should have simplification logic there.
Also improve a bunch of inadequate/obsolete/wrong comments.
Per discussion of a report from Alan Jackson (though this fixes only one
aspect of that problem). Back-patch to v11 where this code came in.
David Rowley, with some further hacking by me
Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
Remove obsolete nbtree insertion comment.
commit : 489e431ba56b10f5736fb54a045ca40880f11bbc
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 15 May 2019 16:53:11 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 15 May 2019 16:53:11 -0700 Remove a Berkeley-era comment above _bt_insertonpg() that admonishes the
reader to grok Lehman and Yao's paper before making any changes. This
made a certain amount of sense back when _bt_insertonpg() was
responsible for most of the things that are now spread across
_bt_insertonpg(), _bt_findinsertloc(), _bt_insert_parent(), and
_bt_split(), but it doesn't work like that anymore.
I believe that this comment alludes to the need to "couple" or "crab"
buffer locks as we ascend the tree as page splits cascade upwards. The
nbtree README already explains this in detail, which seems sufficient.
Besides, the changes to page splits made by commit 40dae7ec537 altered
the exact details of how buffer locks are retained during splits; Lehman
and Yao's original algorithm seems to release the lock on the left child
page/buffer slightly earlier than _bt_insertonpg()/_bt_insert_parent()
can. M src/backend/access/nbtree/nbtinsert.c
Remove no-longer-used typedef.
commit : 8a0f0ad54047c8dc1430e521e2dc90f2cd138a9d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 May 2019 17:26:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 May 2019 17:26:52 -0400 struct ClonedConstraint is no longer needed, so delete it.
Discussion: https://postgr.es/m/18102.1557947143@sss.pgh.pa.us M src/include/catalog/pg_constraint.h
Reverse order of newitem nbtree candidate splits.
commit : 7505da2f459776a397177f7d591991f5591c2812
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 15 May 2019 12:22:07 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 15 May 2019 12:22:07 -0700 Commit fab25024, which taught nbtree to choose candidate split points
more carefully, had _bt_findsplitloc() record all possible split points
in an initial pass over a page that is about to be split. The order
that candidate split points were processed and stored in was assumed to
match the offset number order of split points on an imaginary version of
the page that contains the same items as the original, but also fits
newitem (the item that provoked the split precisely because it didn't
fit).
However, the order of split points in the final array was not quite what
was expected: the split point that makes newitem the firstright item
came after the split point that makes newitem the lastleft item -- not
before. As a result, _bt_findsplitloc() could get confused about the
leftmost and rightmost tuples among all possible split points recorded
for the page. This seems to have no appreciable impact on the quality
of the final split point chosen by _bt_findsplitloc(), but it's still
wrong.
To fix, switch the order in which newitem candidate splits are recorded
in. This also makes it possible to describe candidate split points in
terms of which pair of adjoining tuples enclose the split point within
_bt_findsplitloc(), making it clearer why it's generally safe for
_bt_split() to expect lastleft and firstright tuples. M src/backend/access/nbtree/nbtsplitloc.c
docs: properly indent PG 12 release notes
commit : a429164ef31fc6899cef4d5e4f3f2ce8fc33aa27
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 15 May 2019 12:44:59 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 15 May 2019 12:44:59 -0400 M doc/src/sgml/release-12.sgml
Handle table_complete_speculative’s succeeded argument as documented.
commit : aa4b8c61d2cd57b53be03defb04d59b232a0e150
author : Andres Freund <andres@anarazel.de>
date : Tue, 14 May 2019 12:11:26 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 14 May 2019 12:11:26 -0700 For some reason both callsite and the implementation for heapam had
the meaning inverted (i.e. succeeded == true was passed in case of
conflict). That's confusing.
I (Andres) briefly pondered whether it'd be better to rename
table_complete_speculative's argument to 'bool specConflict' or such,
but decided not to. The 'complete' in the function name for me makes
`succeeded` sound a bit better.
Reported-By: Ashwin Agrawal, Melanie Plageman, Heikki Linnakangas
Discussion:
https://postgr.es/m/CALfoeitk7-TACwYv3hCw45FNPjkA86RfXg4iQ5kAOPhR+F1Y4w@mail.gmail.com
https://postgr.es/m/97673451-339f-b21e-a781-998d06b1067c@iki.fi M src/backend/access/heap/heapam_handler.c
M src/backend/executor/nodeModifyTable.c
Add isolation test for INSERT ON CONFLICT speculative insertion failure.
commit : 08e2edc0767ab6e619970f165cb34d4673105f23
author : Andres Freund <andres@anarazel.de>
date : Tue, 14 May 2019 11:45:40 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 14 May 2019 11:45:40 -0700 This path previously was not reliably covered. There was some
heuristic coverage via insert-conflict-toast.spec, but that test is
not deterministic, and only tested for a somewhat specific bug.
Backpatch, as this is a complicated and otherwise untested code
path. Unfortunately 9.5 cannot handle two waiting sessions, and thus
cannot execute this test.
Triggered by a conversion with Melanie Plageman.
Author: Andres Freund
Discussion: https://postgr.es/m/CAAKRu_a7hbyrk=wveHYhr4LbcRnRCG=yPUVoQYB9YO1CdUBE9Q@mail.gmail.com
Backpatch: 9.5- A src/test/isolation/expected/insert-conflict-specconflict.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/insert-conflict-specconflict.spec
Fix “make clean” to clean out junk files left behind after ssl tests.
commit : 6d2fba3189608186d1a196a595f21760412ec5e8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 14:28:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 14:28:33 -0400 We .gitignore'd this junk, but we didn't actually remove it. M src/test/ssl/Makefile
Move logging.h and logging.c from src/fe_utils/ to src/common/.
commit : fc9a62af3f87f4bec1e8c904ea99ae50f3c881ef
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 14:19:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 14:19:49 -0400 The original placement of this module in src/fe_utils/ is ill-considered,
because several src/common/ modules have dependencies on it, meaning that
libpgcommon and libpgfeutils now have mutual dependencies. That makes it
pointless to have distinct libraries at all. The intended design is that
libpgcommon is lower-level than libpgfeutils, so only dependencies from
the latter to the former are acceptable.
We already have the precedent that fe_memutils and a couple of other
modules in src/common/ are frontend-only, so it's not stretching anything
out of whack to treat logging.c as a frontend-only module in src/common/.
To the extent that such modules help provide a common frontend/backend
environment for the rest of common/ to use, it's a reasonable design.
(logging.c does not yet provide an ereport() emulation, but one can
dream.)
Hence, move these files over, and revert basically all of the build-system
changes made by commit cc8d41511. There are no places that need to grow
new dependencies on libpgcommon, further reinforcing the idea that this
is the right solution.
Discussion: https://postgr.es/m/a912ffff-f6e4-778a-c86a-cf5c47a12933@2ndquadrant.com M src/bin/initdb/initdb.c
M src/bin/pg_archivecleanup/Makefile
M src/bin/pg_archivecleanup/pg_archivecleanup.c
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/pg_recvlogical.c
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/streamutil.c
M src/bin/pg_checksums/Makefile
M src/bin/pg_checksums/pg_checksums.c
M src/bin/pg_controldata/Makefile
M src/bin/pg_controldata/pg_controldata.c
M src/bin/pg_ctl/Makefile
M src/bin/pg_ctl/pg_ctl.c
M src/bin/pg_dump/common.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_custom.c
M src/bin/pg_dump/pg_backup_db.c
M src/bin/pg_dump/pg_backup_utils.h
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump_sort.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_dump/pg_restore.c
M src/bin/pg_resetwal/Makefile
M src/bin/pg_resetwal/pg_resetwal.c
M src/bin/pg_rewind/Makefile
M src/bin/pg_rewind/datapagemap.c
M src/bin/pg_rewind/pg_rewind.h
M src/bin/pg_test_fsync/Makefile
M src/bin/pg_test_fsync/pg_test_fsync.c
M src/bin/pg_upgrade/pg_upgrade.c
M src/bin/pg_waldump/Makefile
M src/bin/pg_waldump/pg_waldump.c
M src/bin/pgbench/pgbench.c
M src/bin/psql/command.c
M src/bin/psql/common.c
M src/bin/psql/copy.c
M src/bin/psql/crosstabview.c
M src/bin/psql/describe.c
M src/bin/psql/help.c
M src/bin/psql/input.c
M src/bin/psql/large_obj.c
M src/bin/psql/mainloop.c
M src/bin/psql/psqlscanslash.l
M src/bin/psql/startup.c
M src/bin/psql/variables.c
M src/bin/scripts/clusterdb.c
M src/bin/scripts/common.c
M src/bin/scripts/createdb.c
M src/bin/scripts/createuser.c
M src/bin/scripts/dropdb.c
M src/bin/scripts/dropuser.c
M src/bin/scripts/pg_isready.c
M src/bin/scripts/reindexdb.c
M src/bin/scripts/vacuumdb.c
M src/common/Makefile
M src/common/controldata_utils.c
M src/common/file_utils.c
R092 src/fe_utils/logging.c src/common/logging.c
M src/common/pgfnames.c
M src/common/restricted_token.c
M src/common/rmtree.c
M src/fe_utils/Makefile
M src/fe_utils/psqlscan.l
R092 src/include/fe_utils/logging.h src/include/common/logging.h
M src/interfaces/ecpg/test/Makefile
M src/nls-global.mk
M src/test/isolation/Makefile
M src/test/regress/GNUmakefile
M src/test/regress/pg_regress.c
M src/tools/msvc/Mkvcbuild.pm
docs: Indent listitem tags in PG 12 release notes
commit : b71dad22ce8a645a47c01e544f640f35b91bfbd3
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 13:32:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 13:32:03 -0400 M doc/src/sgml/release-12.sgml
Remove pg_rewind’s private logging.h/logging.c files.
commit : 53ddefbaf8a0493d2c1fa0b18bfaba72da556985
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 13:11:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 13:11:23 -0400 The existence of these files became rather confusing with the
introduction of a widely-known logging.h header in commit cc8d41511.
(Indeed, there's already some duplicative #includes here, perhaps
betraying such confusion.) The only thing left in them, after that
commit, is a progress-reporting function that's neither general-purpose
nor tied in any way to other logging infrastructure. Hence, let's just
move that function to pg_rewind.c, and get rid of the separate files.
Discussion: https://postgr.es/m/3971.1557787914@sss.pgh.pa.us M src/bin/pg_rewind/Makefile
M src/bin/pg_rewind/copy_fetch.c
M src/bin/pg_rewind/file_ops.c
M src/bin/pg_rewind/filemap.c
M src/bin/pg_rewind/libpq_fetch.c
D src/bin/pg_rewind/logging.c
D src/bin/pg_rewind/logging.h
M src/bin/pg_rewind/nls.mk
M src/bin/pg_rewind/parsexlog.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pg_rewind/pg_rewind.h
M src/bin/pg_rewind/timeline.c
Fix SQL-style substring() to have spec-compliant greediness behavior.
commit : 7c850320d8cfa5503ecec61c2559661b924f7595
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 11:27:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 11:27:31 -0400 SQL's regular-expression substring() function is defined to have a
pattern argument that's separated into three subpatterns by escape-
double-quote markers; the function result is the part of the input
matching the second subpattern. The standard makes it clear that
if there is ambiguity about how to match the input to the subpatterns,
the first and third subpatterns should be taken to match the smallest
possible amount of text (i.e., they're "non greedy", in the terms of
our regex code). We were not doing it that way: the first subpattern
would eat the largest possible amount of text, causing the function
result to be shorter than what the spec requires.
Fix that by attaching explicit greediness quantifiers to the
subpatterns. (This depends on the regex fix in commit 8a29ed053;
before that, this didn't reliably change the regex engine's behavior.)
Also, by adding parentheses around each subpattern, we ensure that
"|" (OR) in the subpatterns behave sanely. Previously, "|" in the
first or third subpatterns didn't work.
This patch also makes the function throw error if you write more than
two escape-double-quote markers, and do something sane if you write
just one, and document that behavior. Previously, an odd number of
markers led to a confusing complaint about unbalanced parentheses,
while extra pairs of markers were just ignored. (Note that the spec
requires exactly two markers, but we've historically allowed there
to be none, and this patch preserves the old behavior for that case.)
In passing, adjust some substring() test cases that didn't really
prove what they said they were testing for: they used patterns
that didn't match the data string, so that the output would be
NULL whether or not the function was really strict.
Although this is certainly a bug fix, changing the behavior in back
branches seems undesirable: applications could perhaps be depending on
the old behavior, since it's not obviously wrong unless you read the
spec very closely. Hence, no back-patch.
Discussion: https://postgr.es/m/5bb27a41-350d-37bf-901e-9d26f5592dd0@charter.net M doc/src/sgml/func.sgml
M src/backend/utils/adt/regexp.c
M src/test/regress/expected/strings.out
M src/test/regress/sql/strings.sql
In bootstrap mode, use default signal handling for SIGINT etc.
commit : fb489e4b3195fc33cccc0fd308e5a0ab502cf199
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 10:22:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 10:22:28 -0400 Previously, the code pointed the standard process-termination signals
to postgres.c's die(). That would typically result in an attempt to
execute a transaction abort, which is not possible in bootstrap mode,
leading to PANIC. This choice seems to be a leftover from an old code
structure in which the same signal-assignment code was used for many
sorts of auxiliary processes, including interactive standalone
backends. It's not very sensible for bootstrap mode, which has no
interest in either interactivity or continuing after an error. We can
get better behavior with less effort by just letting normal process
termination happen, after which the parent initdb process will clean up.
This is basically cosmetic in any case, since initdb will react the
same way whether bootstrap dies on a signal or abort(). Given the
lack of previous complaints, I don't feel a need to back-patch,
even though the behavior is old.
Discussion: https://postgr.es/m/3850b11a.5121.16aaf827e4a.Coremail.thunder1@126.com M src/backend/bootstrap/bootstrap.c
Update SQL features/conformance information to SQL:2016
commit : 037165ca95d854e04c0c28cfa85f1515bd852892
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 14:56:58 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 14:56:58 +0200 M doc/src/sgml/features.sgml
M src/backend/catalog/information_schema.sql
M src/backend/catalog/sql_features.txt
M src/include/catalog/catversion.h
Update information_schema for SQL:2016
commit : eb3a1376c98a1d220354b468f4b09e4a1dca909a
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 15:15:05 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 15:15:05 +0200 This is mainly a light renumbering to match the sections in the
standard. M src/backend/catalog/information_schema.sql
Update SQL keywords list to SQL:2016
commit : c29ba98189190288c2251c6073c13c6234479e5c
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 09:56:40 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 09:56:40 +0200 Per previous convention (see
ace397e9d24eddc56e7dffa921f506117b602d78), drop SQL:2008 and only keep
the latest two standards and SQL-92.
Note: SQL:2016-2 lists a large number of non-reserved keywords that
are really just information_schema column names related to new
features. Those kinds of thing have not previously been listed as
keywords, and this was apparently done here by mistake, since these
keywords have been removed again in post-2016 working drafts. So in
order to avoid bloating the keywords table unnecessarily, I have
omitted these erroneous keywords here. M doc/src/sgml/generate-keywords-table.pl
R090 doc/src/sgml/keywords/sql2008-02-nonreserved.txt doc/src/sgml/keywords/sql2016-02-nonreserved.txt
R082 doc/src/sgml/keywords/sql2008-02-reserved.txt doc/src/sgml/keywords/sql2016-02-reserved.txt
R100 doc/src/sgml/keywords/sql2008-09-nonreserved.txt doc/src/sgml/keywords/sql2016-09-nonreserved.txt
R100 doc/src/sgml/keywords/sql2008-09-reserved.txt doc/src/sgml/keywords/sql2016-09-reserved.txt
R093 doc/src/sgml/keywords/sql2008-14-nonreserved.txt doc/src/sgml/keywords/sql2016-14-nonreserved.txt
R100 doc/src/sgml/keywords/sql2008-14-reserved.txt doc/src/sgml/keywords/sql2016-14-reserved.txt
docs: update partition item in PG 12 release notes
commit : 356c83795aaa39cfd9bca588bfe4f0196710962e
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 09:17:08 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 09:17:08 -0400 Reported-by: Amit Langote
Discussion: https://postgr.es/m/b7954643-41ef-a174-479d-1f8d4834f40a@lab.ntt.co.jp M doc/src/sgml/release-12.sgml
docs: fix duplicate wording in PG 12 release notes
commit : 34d40becfa7a5c7343d0079f181597d7e06122e1
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 09:06:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 09:06:03 -0400 Reported-by: nickb@imap.cc
Discussion: https://postgr.es/m/6b3414e1-fcef-4ad9-b123-b3ab3702d3db@www.fastmail.com M doc/src/sgml/release-12.sgml
Detect internal GiST page splits correctly during index build.
commit : 22251686f07f70527aecda22ab5402986884f6f5
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 May 2019 13:18:44 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 May 2019 13:18:44 +0300 As we descend the GiST tree during insertion, we modify any downlinks on
the way down to include the new tuple we're about to insert (if they don't
cover it already). Modifying an existing downlink might cause an internal
page to split, if the new downlink tuple is larger than the old one. If
that happens, we need to back up to the parent and re-choose a page to
insert to. We used to detect that situation, thanks to the NSN-LSN
interlock normally used to detect concurrent page splits, but that got
broken by commit 9155580fd5. With that commit, we now use a dummy constant
LSN value for every page during index build, so the LSN-NSN interlock no
longer works. I thought that was OK because there can't be any other
backends modifying the index during index build, but missed that the
insertion itself can modify the page we're inserting to. The consequence
was that we would sometimes insert the new tuple to an incorrect page, one
whose downlink doesn't cover the new tuple.
To fix, add a flag to the stack that keeps track of the state while
descending tree, to indicate that a page was split, and that we need to
retry the descend from the parent.
Thomas Munro first reported that the contrib/intarray regression test was
failing occasionally on the buildfarm after commit 9155580fd5. The failure
was intermittent, because the gistchoose() function is not deterministic,
and would only occasionally create the right circumstances for this bug to
cause the failure.
Patch by Anastasia Lubennikova, with some changes by me to make it work
correctly also when the internal page split also causes the "grandparent"
to be split.
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGJRzLo7tZExWfSbwM3XuK7aAK7FhdBV0FLkbUG%2BW0v0zg%40mail.gmail.com M src/backend/access/gist/gist.c
M src/include/access/gist_private.h
Fix comment on when HOT update is possible.
commit : e95d550bbbe21f51d329fbae84cbac3545a9e650
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 May 2019 13:06:28 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 May 2019 13:06:28 +0300 The conditions listed in this comment have changed several times, and at
some point the thing that the "if so" referred to was negated.
The text was OK up to 9.6. It was differently wrong in v10, v11 and
master, so fix in all those versions. M src/backend/access/heap/heapam.c
Fix typo.
commit : 7d9eca59cf958eb8c8ff47c40003392681a9ce68
author : Etsuro Fujita <efujita@postgresql.org>
date : Tue, 14 May 2019 16:05:37 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Tue, 14 May 2019 16:05:37 +0900 M src/backend/utils/misc/postgresql.conf.sample
doc: Update OID item in PG 12 release notes
commit : 0b62f0f2552d895301fdae56aa839c1eaae24a3a
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:55:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:55:38 -0400 Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190513174759.GE23251@telsasoft.com M doc/src/sgml/release-12.sgml
doc: improve wording of PG 12 releaase note partition item
commit : f4125278e3c92d8cdd83c77d0b54f468ee81c750
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:38:50 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:38:50 -0400 Reported-by: Amit Langote
Discussion: https://postgr.es/m/d5267ae5-bd4a-3e96-c21b-56bfa9fec7e8@lab.ntt.co.jp M doc/src/sgml/release-12.sgml
doc: properly attibute PG 12 pgbench release note item
commit : 5d971565a7993ba8dcd06d34d1387af48fdbd034
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:21:32 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:21:32 -0400 Reported-by: Fabien COELHO
Discussion: https://postgr.es/m/alpine.DEB.2.21.1905130839140.13487@lancre M doc/src/sgml/release-12.sgml
Fix duplicated words in comments
commit : 7e19929ea29668f3d01280262e407b93042c959a
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 14 May 2019 09:37:35 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 14 May 2019 09:37:35 +0900 Author: Stephen Amell
Discussion: https://postgr.es/m/539fa271-21b3-777e-a468-d96cffe9c768@gmail.com M src/backend/executor/execExpr.c
M src/backend/replication/logical/reorderbuffer.c
M src/include/c.h
M src/include/jit/llvmjit_emit.h
M src/include/nodes/execnodes.h
M src/include/replication/logical.h
Standardize ItemIdData terminology.
commit : ae7291acbc5ae4c3751615177fc256f9f3399403
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 15:53:39 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 15:53:39 -0700 The term "item pointer" should not be used to refer to ItemIdData
variables, since that is needlessly ambiguous. Only
ItemPointerData/ItemPointer variables should be called item pointers.
To fix, establish the convention that ItemIdData variables should always
be referred to either as "item identifiers" or "line pointers". The
term "item identifier" already predominates in docs and translatable
messages, and so should be the preferred alternative there.
Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com M contrib/amcheck/verify_nbtree.c
M src/backend/access/heap/README.HOT
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/heap/pruneheap.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/access/index/indexam.c
M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/spgist/spgvacuum.c
M src/backend/storage/page/bufpage.c
M src/include/access/htup_details.h
M src/include/access/itup.h
M src/include/storage/bufpage.h
M src/include/storage/itemid.h
Doc: Refer to line pointers as item identifiers.
commit : 08ca9d7feca890e97f77ef1fde02d7542a54ac5e
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 15:39:06 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 15:39:06 -0700 An upcoming HEAD-only patch will standardize the terminology around
ItemIdData variables/line pointers, ending the practice of referring to
them as "item pointers". Make the "Database Page Layout" docs
consistent with the new policy. The term "item identifier" is already
used in the same section, so stick with that.
Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com
Backpatch: All supported branches. M doc/src/sgml/storage.sgml
Fix logical replication’s ideas about which type OIDs are built-in.
commit : 32ebb35128c3d16b64039f6d6774afd96a3d91b9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 17:23:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 17:23:00 -0400 Only hand-assigned type OIDs should be presumed to match across different
PG servers; those assigned during genbki.pl or during initdb are likely
to change due to addition or removal of unrelated objects.
This means that the cutoff should be FirstGenbkiObjectId (in HEAD)
or FirstBootstrapObjectId (before that), not FirstNormalObjectId.
Compare postgres_fdw's is_builtin() test.
It's likely that this error has no observable consequence in a
normally-functioning system, since ATM the only affected type OIDs are
system catalog rowtypes and information_schema types, which would not
typically be interesting for logical replication. But you could
probably break it if you tried hard, so back-patch.
Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us M src/backend/replication/logical/relation.c
M src/backend/replication/pgoutput/pgoutput.c
Improve commentary about hack in is_publishable_class().
commit : e34ee993fbc38c8538f9342c5961e5f61fd45180
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 17:05:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 17:05:48 -0400 The FirstNormalObjectId test here is a kluge that needs to go away,
but the only substitute we can think of is to add a column to pg_class,
which will take more work than can be handled right now. Add some
commentary in the meanwhile.
Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us M src/backend/catalog/pg_publication.c
Don’t leave behind junk nbtree pages during split.
commit : 9b42e713761a43e9ade3965285f077e2ba25bbb7
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 10:27:59 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 10:27:59 -0700 Commit 8fa30f906be reduced the elevel of a number of "can't happen"
_bt_split() errors from PANIC to ERROR. At the same time, the new right
page buffer for the split could continue to be acquired well before the
critical section. This was possible because it was relatively
straightforward to make sure that _bt_split() could not throw an error,
with a few specific exceptions. The exceptional cases were safe because
they involved specific, well understood errors, making it possible to
consistently zero the right page before actually raising an error using
elog(). There was no danger of leaving around a junk page, provided
_bt_split() stuck to this coding rule.
Commit 8224de4f, which introduced INCLUDE indexes, added code to make
_bt_split() truncate away non-key attributes. This happened at a point
that broke the rule around zeroing the right page in _bt_split(). If
truncation failed (perhaps due to palloc() failure), that would result
in an errant right page buffer with junk contents. This could confuse
VACUUM when it attempted to delete the page, and should be avoided on
general principle.
To fix, reorganize _bt_split() so that truncation occurs before the new
right page buffer is even acquired. A junk page/buffer will not be left
behind if _bt_nonkey_truncate()/_bt_truncate() raise an error.
Discussion: https://postgr.es/m/CAH2-WzkcWT_-NH7EeL=Az4efg0KCV+wArygW8zKB=+HoP=VWMw@mail.gmail.com
Backpatch: 11-, where INCLUDE indexes were introduced. M src/backend/access/nbtree/nbtinsert.c
Improve comment for att_isnull.
commit : 221b377f09a30dd7c74c26c8c1db439afcc59141
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 13 May 2019 13:13:24 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 13 May 2019 13:13:24 -0400 The comment implies that a 1 in the null bitmap indicates a null value,
but actually a 0 in the null bitmap indicates a null value. Try to
be more clear.
Patch by me; proposed wording reviewed by Alvaro Herrera and Tom Lane.
Discussion: http://postgr.es/m/CA+TgmobHOP8r6cG+UnsDFMrS30-m=jRrCBhgw-nFkn0k9QnFsg@mail.gmail.com M src/include/access/tupmacs.h
Fix misuse of an integer as a bool.
commit : ddf927fb13471bec0cc76794eaf552df8a1178fb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 10:53:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 10:53:19 -0400 pgtls_read_pending is declared to return bool, but what the underlying
SSL_pending function returns is a count of available bytes.
This is actually somewhat harmless if we're using C99 bools, but in
the back branches it's a live bug: if the available-bytes count happened
to be a multiple of 256, it would get converted to a zero char value.
On machines where char is signed, counts of 128 and up could misbehave
as well. The net effect is that when using SSL, libpq might block
waiting for data even though some has already been received.
Broken by careless refactoring in commit 4e86f1b16, so back-patch
to 9.5 where that came in.
Per bug #15802 from David Binderman.
Discussion: https://postgr.es/m/15802-f0911a97f0346526@postgresql.org M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/fe-secure-openssl.c
postgres_fdw: Fix typo in comment.
commit : cc866941ad4583f07e5637c145f6f6ee8a573e11
author : Etsuro Fujita <efujita@postgresql.org>
date : Mon, 13 May 2019 17:30:35 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Mon, 13 May 2019 17:30:35 +0900 M contrib/postgres_fdw/postgres_fdw.c
doc: PG 12 release notes: normalize attribution names
commit : f86b0c3c465319b80d71db7d7a9de636950e104a
author : Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:54:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:54:02 -0400 Reported-by: David Rowley
Discussion: https://postgr.es/m/CAKJS1f-ktEhmQ2zJQ1L1niuJ9KB8WPA-bE-AhGiFsSO6QASB_w@mail.gmail.com M doc/src/sgml/release-12.sgml
doc: adjust PG 12 release note sections
commit : a6927996be59ac329d65d41cf058d0b1b0978eeb
author : Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:41:53 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:41:53 -0400 Tighten section designations. M doc/src/sgml/release-12.sgml
docs: fix typo in mention of MSVC
commit : fefb6a75386b72a40f697523953eafc7cb1c7a5b
author : Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:24:43 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:24:43 -0400 M doc/src/sgml/release-12.sgml
Fix incorrect return value in JSON equality function for scalars
commit : 1171dbde2daef8f0dcd1dc1e54531a0d8dd34d88
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 13 May 2019 09:11:50 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 13 May 2019 09:11:50 +0900 equalsJsonbScalarValue() uses a boolean as return type, however for one
code path -1 gets returned, which is confusing. The origin of the
confusion is visibly that this code got copy-pasted from
compareJsonbScalarValue() since it has been introduced in d1d50bf.
No backpatch, as this is only cosmetic.
Author: Rikard Falkeborn
Discussion: https://postgr.es/m/CADRDgG7mJnek6HNW13f+LF6V=6gag9PM+P7H5dnyWZAv49aBGg@mail.gmail.com M src/backend/utils/adt/jsonb_util.c
Fix misoptimization of “{1,1}” quantifiers in regular expressions.
commit : 8a29ed05302ea18b4be177c2d1181b43706af45f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 12 May 2019 18:53:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 12 May 2019 18:53:12 -0400 A bounded quantifier with m = n = 1 might be thought a no-op. But
according to our documentation (which traces back to Henry Spencer's
original man page) it still imposes greediness, or non-greediness in the
case of the non-greedy variant "{1,1}?", on whatever it's attached to.
This turns out not to work though, because parseqatom() optimizes away
the m = n = 1 case without regard for whether it's supposed to change
the greediness of the argument RE.
We can fix this by just not applying the optimization when the greediness
needs to change; the subsequent general cases handle it fine.
The three cases in which we can still apply the optimization are
(a) no quantifier, or quantifier does not impose a preference;
(b) atom has no greediness property, implying it cannot match a
variable amount of text anyway; or
(c) quantifier's greediness is same as atom's.
Note that in most cases where one of these applies, we'd have exited
earlier in the "not a messy case" fast path. I think it's now only
possible to get to the optimization when the atom involves capturing
parentheses or a non-top-level backref.
Back-patch to all supported branches. I'd ordinarily be hesitant to
put a subtle behavioral change into back branches, but in this case
it's very hard to see a reason why somebody would write "{1,1}?" unless
they're trying to get the documented change-of-greediness behavior.
Discussion: https://postgr.es/m/5bb27a41-350d-37bf-901e-9d26f5592dd0@charter.net M src/backend/regex/regcomp.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Fail pgwin32_message_to_UTF16() for SQL_ASCII messages.
commit : d02768ddd1791bab742cf131de726d0a36b3f337
author : Noah Misch <noah@leadboat.com>
date : Sun, 12 May 2019 10:33:05 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 12 May 2019 10:33:05 -0700 The function had been interpreting SQL_ASCII messages as UTF8, throwing
an error when they were invalid UTF8. The new behavior is consistent
with pg_do_encoding_conversion(). This affects LOG_DESTINATION_STDERR
and LOG_DESTINATION_EVENTLOG, which will send untranslated bytes to
write() and ReportEventA(). On buildfarm member bowerbird, enabling
log_connections caused an error whenever the role name was not valid
UTF8. Back-patch to 9.4 (all supported versions).
Discussion: https://postgr.es/m/20190512015615.GD1124997@rfd.leadboat.com M src/backend/utils/mb/mbutils.c
M src/bin/pg_dump/t/010_dump_connstr.pl
M src/bin/scripts/t/200_connstr.pl
Rearrange pgstat_bestart() to avoid failures within its critical section.
commit : 85ccb6899c6c8639bb3e5962ea3bcce5d886e613
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 May 2019 21:27:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 May 2019 21:27:13 -0400 We long ago decided to design the shared PgBackendStatus data structure to
minimize the cost of writing status updates, which means that writers just
have to increment the st_changecount field twice. That isn't hooked into
any sort of resource management mechanism, which means that if something
were to throw error between the two increments, the st_changecount field
would be left odd indefinitely. That would cause readers to lock up.
Now, since it's also a bad idea to leave the field odd for longer than
absolutely necessary (because readers will spin while we have it set),
the expectation was that we'd treat these segments like spinlock critical
sections, with only short, more or less straight-line, code in them.
That was fine as originally designed, but commit 9029f4b37 broke it
by inserting a significant amount of non-straight-line code into
pgstat_bestart(), code that is very capable of throwing errors, not to
mention taking a significant amount of time during which readers will spin.
We have a report from Neeraj Kumar of readers actually locking up, which
I suspect was due to an encoding conversion error in X509_NAME_to_cstring,
though conceivably it was just a garden-variety OOM failure.
Subsequent commits have loaded even more dubious code into pgstat_bestart's
critical section (and commit fc70a4b0d deserves some kind of booby prize
for managing to miss the critical section entirely, although the negative
consequences seem minimal given that the PgBackendStatus entry should be
seen by readers as inactive at that point).
The right way to fix this mess seems to be to compute all these values
into a local copy of the process' PgBackendStatus struct, and then just
copy the data back within the critical section proper. This plan can't
be implemented completely cleanly because of the struct's heavy reliance
on out-of-line strings, which we must initialize separately within the
critical section. But still, the critical section is far smaller and
safer than it was before.
In hopes of forestalling future errors of the same ilk, rename the
macros for st_changecount management to make it more apparent that
the writer-side macros create a critical section. And to prevent
the worst consequences if we nonetheless manage to mess it up anyway,
adjust those macros so that they really are a critical section, ie
they now bump CritSectionCount. That doesn't add much overhead, and
it guarantees that if we do somehow throw an error while the counter
is odd, it will lead to PANIC and a database restart to reset shared
memory.
Back-patch to 9.5 where the problem was introduced.
In HEAD, also fix an oversight in commit b0b39f72b: it failed to teach
pgstat_read_current_status to copy st_gssstatus data from shared memory to
local memory. Hence, subsequent use of that data within the transaction
would potentially see changing data that it shouldn't see.
Discussion: https://postgr.es/m/CAPR3Wj5Z17=+eeyrn_ZDG3NQGYgMEOY6JV6Y-WRRhGgwc16U3Q@mail.gmail.com M src/backend/postmaster/pgstat.c
M src/include/pgstat.h
docs: remove second mention of btree max length reduction
commit : 4217d15d91128355ea13e6fb9c031b826e2a1335
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 18:24:31 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 18:24:31 -0400 I already added that to the incompatibility section as a separate item.
Reported-by: Peter Geoghegan M doc/src/sgml/release-12.sgml
doc: remove pg_config mention from PG 12 release notes
commit : 31f11f964734dbe2af2915182bf79f69e337d4d7
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 17:59:58 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 17:59:58 -0400 Reported-by: Tom Lane
Discussion: https://postgr.es/m/28209.1556556696@sss.pgh.pa.us M doc/src/sgml/release-12.sgml
docs: PG 12 release notes, mention that REINDEX could now fail
commit : d56fd6357a5e0e76fecf20c3dc762c5301290331
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 16:42:05 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 16:42:05 -0400 This is because of the new tid in the index entry.
Reported-by: Peter Geoghegan M doc/src/sgml/release-12.sgml
docs: add links from the PG 12 release notes to the main docs
commit : 1708974485e82e1cf4694c683faa70fc5bcf142c
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 16:17:18 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 16:17:18 -0400 M doc/src/sgml/release-12.sgml
docs: adjust PG 12 floating point item
commit : 0edc8fc47bc4482ceac85b09575d6372dbbc0bbf
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 10:29:30 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 10:29:30 -0400 Reported-by: Andrew Gierth
Discussion: https://postgr.es/m/87r295hjur.fsf@news-spur.riddles.org.uk M doc/src/sgml/release-12.sgml
Honor TEMP_CONFIG in TAP suites.
commit : 54c2ecb56707ed00844b8678a79570dd34cb95a3
author : Noah Misch <noah@leadboat.com>
date : Sat, 11 May 2019 00:22:38 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 11 May 2019 00:22:38 -0700 The buildfarm client uses TEMP_CONFIG to implement its extra_config
setting. Except for stats_temp_directory, extra_config now applies to
TAP suites; extra_config values seen in the past month are compatible
with this. Back-patch to 9.6, where PostgresNode was introduced, so the
buildfarm can rely on it sooner.
Reviewed by Andrew Dunstan and Tom Lane.
Discussion: https://postgr.es/m/20181229021950.GA3302966@rfd.leadboat.com M src/bin/pg_ctl/t/001_start_stop.pl
M src/test/perl/PostgresNode.pm
Fix error reporting in reindexdb
commit : e51bad8fb4c3f0ad5cb173034afdc0b349c7e488
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 11 May 2019 13:00:54 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 11 May 2019 13:00:54 +0900 When failing to reindex a table or an index, reindexdb would generate an
extra error message related to a database failure, which is misleading.
Backpatch all the way down, as this has been introduced by 85e9a5a0.
Discussion: https://postgr.es/m/CAOBaU_Yo61RwNO3cW6WVYWwH7EYMPuexhKqufb2nFGOdunbcHw@mail.gmail.com
Author: Julien Rouhaud
Reviewed-by: Daniel Gustafsson, Álvaro Herrera, Tom Lane, Michael
Paquier
Backpatch-through: 9.4 M src/bin/scripts/reindexdb.c
Fix editing error in floating-point docs.
commit : b721e201a0bcf0f9e1795c295e134e47d698e80c
author : Andrew Gierth <rhodiumtoad@postgresql.org>
date : Sat, 11 May 2019 03:23:55 +0100
committer: Andrew Gierth <rhodiumtoad@postgresql.org>
date : Sat, 11 May 2019 03:23:55 +0100 My fault; the error was introduced in the Ryu patch. M doc/src/sgml/datatype.sgml
doc: add Heikki to PG 12 release note btree item
commit : 064df0edfee91d3843d54d1f67c05a4634690a12
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 22:11:13 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 22:11:13 -0400 Reported-by: Peter Geoghegan
Discussion: https://postgr.es/m/CAH2-WzkrX-aA7d3OYtQT+8Mspq+tU5vwuVz=FTzMH3CdrSyprA@mail.gmail.com M doc/src/sgml/release-12.sgml
doc: improve PG 12 item on partitioned tables
commit : 13d258ec0e55ebc4378e848934f0f4c0ffac0a6f
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:22:53 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:22:53 -0400 Reported-by: Amit Langote
Discussion: https://postgr.es/m/5936b052-5d92-a2c9-75d2-0245fb2330b5@lab.ntt.co.jp M doc/src/sgml/release-12.sgml
doc: reorder attribution of PG 12 btree item
commit : 05f9eba3498f4dbc8687f66eff53a2bfb88f2595
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:16:33 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:16:33 -0400 Reported-by: Alexander Korotkov
Discussion: https://postgr.es/m/CAPpHfdvkM-PkyrK6LQitJUDmC_1kOCEtTuseoVhCT=ew0XJmGg@mail.gmail.com M doc/src/sgml/release-12.sgml
docs: properly attribute PG 12 rel item to James Coleman
commit : 8aa1b0885e3d248dbf3e0b0c544125d13dbc36d0
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:06:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:06:38 -0400 Reported-by: David Rowley
Discussion: https://postgr.es/m/CAKJS1f-NDmeA_tb0oRFhrgf19xq3A9MeoyMcckY04Ct=_i0c2A@mail.gmail.com M doc/src/sgml/release-12.sgml
docs: PG 12 docs, clarify btree index changes
commit : 809e248299894b02e8f4eb3ee17829b2ae14ce9d
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:03:31 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:03:31 -0400 Reported-by: Peter Geoghegan
Discussion: https://postgr.es/m/CAH2-WzkSYOM1GJVGtAbRW-OqymoCD=QWYG6ro+GaoOW-jPRuDQ@mail.gmail.com M doc/src/sgml/release-12.sgml
doc: PG 12 release note adjustment
commit : b299efaea433a7d2c04ce124e4f6588807bbe87a
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 20:25:52 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 20:25:52 -0400 Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190510013449.GL3925@telsasoft.com M doc/src/sgml/release-12.sgml
Remove reindex_catalog test from test schedules.
commit : 5997a8f4d7478ae6bac4dab12ca1f883e41a7aa1
author : Andres Freund <andres@anarazel.de>
date : Sun, 5 May 2019 23:31:58 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 5 May 2019 23:31:58 -0700 As none of the approaches for avoiding the deadlock issues seem
promising enough, and all the expected reindex related changes have
been made, apply 60c2951e1bab7e to master as well.
Discussion: https://postgr.es/m/4622.1556982247@sss.pgh.pa.us M src/test/regress/expected/reindex_catalog.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/reindex_catalog.sql
Cope with EINVAL and EIDRM shmat() failures in PGSharedMemoryAttach.
commit : 610747d86e46ae6e94b7288393d08823cc39b498
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 May 2019 14:56:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 May 2019 14:56:41 -0400 There's a very old race condition in our code to see whether a pre-existing
shared memory segment is still in use by a conflicting postmaster: it's
possible for the other postmaster to remove the segment in between our
shmctl() and shmat() calls. It's a narrow window, and there's no risk
unless both postmasters are using the same port number, but that's possible
during parallelized "make check" tests. (Note that while the TAP tests
take some pains to choose a randomized port number, pg_regress doesn't.)
If it does happen, we treated that as an unexpected case and errored out.
To fix, allow EINVAL to be treated as segment-not-present, and the same
for EIDRM on Linux. AFAICS, the considerations here are basically
identical to the checks for acceptable shmctl() failures, so I documented
and coded it that way.
While at it, adjust PGSharedMemoryAttach's API to remove its undocumented
dependency on UsedShmemSegAddr in favor of passing the attach address
explicitly. This makes it easier to be sure we're using a null shmaddr
when probing for segment conflicts (thus avoiding questions about what
EINVAL means). I don't think there was a bug there, but it required
fragile assumptions about the state of UsedShmemSegAddr during
PGSharedMemoryIsInUse.
Commit c09850992 may have made this failure more probable by applying
the conflicting-segment tests more often. Hence, back-patch to all
supported branches, as that was.
Discussion: https://postgr.es/m/22224.1557340366@sss.pgh.pa.us M src/backend/port/sysv_shmem.c
doc: add markup for PG 12 release note text
commit : c65bcfe9aeecae1c6204ad60612fae43669a88b0
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 23:26:48 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 23:26:48 -0400 I will add links to other parts of the docs later. M doc/src/sgml/release-12.sgml
doc: PG 12 wording improvments
commit : d0bbf871ca243eafcac7a84138741521c1aea3d2
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:58:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:58:02 -0400 Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190510001335.GJ3925@telsasoft.com M doc/src/sgml/release-12.sgml
Fix and improve description of locktag types in lock.h
commit : 752f06443fba7e906cd98987f247297663f19a16
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 10 May 2019 09:35:27 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 10 May 2019 09:35:27 +0900 The description of the lock type for speculative insertions was
incorrect, being copy-pasted from another one.
As discussed, also move the description for all the fields of lock tag
types from the structure listing lock tag types to the set of macros
setting each LOCKTAG.
Author: John Naylor
Discussion: https://postgr.es/m/CACPNZCtA0-ybaC4fFfaDq_8p_TUOLvGxZH9Dm-=TMHZJarBa7Q@mail.gmail.com M src/include/storage/lock.h
doc: more PG 12 wording adjustments
commit : 97b1654da7dd38fa50c9b6139f4213a1c47f0c39
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:32:35 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:32:35 -0400 Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190510001959.GK3925@telsasoft.com M doc/src/sgml/release-12.sgml
doc: fix capitalization in PG 12 release notes
commit : 32fe7ee2dd2b2aa8620e69451f60b2b35989677c
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:10:17 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:10:17 -0400 Reported-by: Thomas Munro
Discussion: https://postgr.es/m/CA+hUKGJpep8uSXoDtVF6iROCRKce-39HEhDPUaYFyMn0U5e9ug@mail.gmail.com M doc/src/sgml/release-12.sgml
doc: more PG 12 release note adjustments
commit : 79697d039f567cd52d844077244fb85df10dce19
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 19:59:59 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 19:59:59 -0400 This adds two more items that should have been included in the
beginning.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190508203204.GA25482@telsasoft.com M doc/src/sgml/release-12.sgml
docs: update release notes with fixes
commit : 81ddfa2e4d9350eb68f28cde8ae6a7e0b39ef2ac
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 19:27:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 19:27:03 -0400 Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190508203204.GA25482@telsasoft.com M doc/src/sgml/release-12.sgml
Improve and fix some error handling for REINDEX INDEX/TABLE CONCURRENTLY
commit : 508300e2e141a9fd87758ce01374c5b0597986fd
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 10 May 2019 08:18:46 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 10 May 2019 08:18:46 +0900 This improves the user experience when it comes to restrict several
flavors of REINDEX CONCURRENTLY. First, for INDEX, remove a restriction
on shared relations as we already check after catalog relations. Then,
for TABLE, add a proper error message when attempting to run the command
on system catalogs. The code path of CREATE INDEX CONCURRENTLY already
complains about that, but if a REINDEX is issued then then the error
generated is confusing.
While on it, add more tests to check restrictions on catalog indexes and
on toast table/index for catalogs. Some error messages are improved,
with wording suggestion coming from Tom Lane.
Reported-by: Tom Lane
Author: Michael Paquier
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/23694.1556806002@sss.pgh.pa.us M src/backend/commands/indexcmds.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Repair issues with faulty generation of merge-append plans.
commit : 24c19e9f66863d83009a370604e40b1eaa71bcdd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 May 2019 16:52:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 May 2019 16:52:48 -0400 create_merge_append_plan failed to honor the CP_EXACT_TLIST flag:
it would generate the expected targetlist but then it felt free to
add resjunk sort targets to it. This demonstrably leads to assertion
failures in v11 and HEAD, and it's probably just accidental that we
don't see the same in older branches. I've not looked into whether
there would be any real-world consequences in non-assert builds.
In HEAD, create_append_plan has sprouted the same problem, so fix
that too (although we do not have any test cases that seem able to
reach that bug). This is an oversight in commit 3fc6e2d7f which
invented the CP_EXACT_TLIST flag, so back-patch to 9.6 where that
came in.
convert_subquery_pathkeys would create pathkeys for subquery output
values if they match any EquivalenceClass known in the outer query
and are available in the subquery's syntactic targetlist. However,
the second part of that condition is wrong, because such values might
not appear in the subquery relation's reltarget list, which would
mean that they couldn't be accessed above the level of the subquery
scan. We must check that they appear in the reltarget list, instead.
This can lead to dropping knowledge about the subquery's sort
ordering, but I believe it's okay, because any sort key that the
outer query actually has any interest in would appear in the
reltarget list.
This second issue is of very long standing, but right now there's no
evidence that it causes observable problems before 9.6, so I refrained
from back-patching further than that. We can revisit that choice if
somebody finds a way to make it cause problems in older branches.
(Developing useful test cases for these issues is really problematic;
fixing convert_subquery_pathkeys removes the only known way to exhibit
the create_merge_append_plan bug, and neither of the test cases added
by this patch causes a problem in all branches, even when considering
the issues separately.)
The second issue explains bug #15795 from Suresh Kumar R ("could not
find pathkey item to sort" with nested DISTINCT queries). I stumbled
across the first issue while investigating that.
Discussion: https://postgr.es/m/15795-fadb56c8e44ee73c@postgresql.org M src/backend/optimizer/path/pathkeys.c
M src/backend/optimizer/plan/createplan.c
M src/test/regress/expected/union.out
M src/test/regress/sql/union.sql
doc: update PG 12 release notes, v2
commit : 64084d6857b1d8ac05ae46f658b6c244aa6ab591
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 16:44:27 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 16:44:27 -0400 Adjustments requested by reviewers.
Reported-by: Amit Kapila, Thomas Munro, Andrew Gierth, Amit Langote, Oleg Bartunov, Michael Paquier, Alvaro Herrera, Tatsuo Ishii
Discussion: https://postgr.es/m/20190506233029.ozwged67i7s4qd6c@momjian.us M doc/src/sgml/release-12.sgml
Doc: Update FDW documentation about GetForeignUpperPaths().
commit : a0be05bab062eff16eafce3df73b3df453a694f4
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 9 May 2019 19:50:15 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 9 May 2019 19:50:15 +0900 In commit d50d172e51, which added support for LIMIT/OFFSET pushdown in
postgres_fdw, a new struct was introduced as the extra parameter of
GetForeignUpperPaths() set for UPPERREL_FINAL, but I forgot to update
the documentation to mention that.
Author: Etsuro Fujita
Discussion: https://postgr.es/m/CAPmGK17uSXQDe31oRb-z1nYyT6vVzkstZkA3_Wbq38U92b9BmQ%40mail.gmail.com M doc/src/sgml/fdwhandler.sgml
postgres_fdw: Fix cost estimation for aggregate pushdown.
commit : edbcbe277d795ecc339b0e4fa29bae42ce1a7be9
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 9 May 2019 18:39:23 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 9 May 2019 18:39:23 +0900 In commit 7012b132d0, which added support for aggregate pushdown in
postgres_fdw, the expense of evaluating the final scan/join target
computed by make_group_input_target() was not accounted for at all in
costing aggregate pushdown paths with local statistics. The right fix
for this would be to have a separate upper stage to adjust the final
scan/join relation (see comments for apply_scanjoin_target_to_paths());
but for now, fix by adding the tlist eval cost when costing aggregate
pushdown paths with local statistics.
Apply this to HEAD only to avoid destabilizing existing plan choices.
Author: Etsuro Fujita
Reviewed-By: Antonin Houska
Discussion: https://postgr.es/m/5C66A056.60007%40lab.ntt.co.jp M contrib/postgres_fdw/postgres_fdw.c
M src/backend/optimizer/plan/planner.c
Fix SxactGlobalXmin tracking.
commit : 47a338cfcd67139a1f91892b080934fcfc3aea03
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 9 May 2019 19:11:46 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 9 May 2019 19:11:46 +1200 Commit bb16aba50 broke the code that maintains SxactGlobalXmin. It
could get stuck when a well-timed READ ONLY transaction runs. If
SxactGlobalXmin stops advancing, transactions on the
FinishedSerializableTransactions queue are never cleaned up, so
resources are effectively leaked. Revert that hunk of the commit.
Also revert another similar hunk that was probably harmless, but
unnecessary and unjustified, relating to the DOOMED flag in case of
RO_SAFE early release.
Author: Thomas Munro
Reported-by: Tom Lane
Discussion: https://postgr.es/m/16170.1557251214%40sss.pgh.pa.us M src/backend/storage/lmgr/predicate.c
pg_controldata: Add common gettext flags
commit : cd805f46d857291b26ba6eb491ce11b6e0fc9ad3
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 9 May 2019 09:15:59 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 9 May 2019 09:15:59 +0200 So it picks up strings in pg_log_* calls. This was forgotten when it
was added to all other relevant subdirectories. M src/bin/pg_controldata/nls.mk
Fix grammar in error message
commit : 02daece4ab4cd85b80d04469056e5b631918c9d6
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 9 May 2019 09:14:37 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 9 May 2019 09:14:37 +0200 M doc/src/sgml/plpgsql.sgml
M src/pl/plpgsql/src/pl_exec.c
M src/test/regress/expected/plpgsql.out
Clean up the behavior and API of catalog.c’s is-catalog-relation tests.
commit : 2d7d946cd323ce1c1d3f3ef0e5f2f41591afc1b9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 May 2019 23:27:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 May 2019 23:27:29 -0400 The right way for IsCatalogRelation/Class to behave is to return true
for OIDs less than FirstBootstrapObjectId (not FirstNormalObjectId),
without any of the ad-hoc fooling around with schema membership.
The previous code was wrong because (1) it claimed that
information_schema tables were not catalog relations but their toast
tables were, which is silly; and (2) if you dropped and recreated
information_schema, which is a supported operation, the behavior
changed. That's even sillier. With this definition, "catalog
relations" are exactly the ones traceable to the postgres.bki data,
which seems like what we want.
With this simplification, we don't actually need access to the pg_class
tuple to identify a catalog relation; we only need its OID. Hence,
replace IsCatalogClass with "IsCatalogRelationOid(oid)". But keep
IsCatalogRelation as a convenience function.
This allows fixing some arguably-wrong semantics in contrib/sepgsql and
ReindexRelationConcurrently, which were using an IsSystemNamespace test
where what they really should be using is IsCatalogRelationOid. The
previous coding failed to protect toast tables of system catalogs, and
also was not on board with the general principle that user-created tables
do not become catalogs just by virtue of being renamed into pg_catalog.
We can also get rid of a messy hack in ReindexMultipleTables.
While we're at it, also rename IsSystemNamespace to IsCatalogNamespace,
because the previous name invited confusion with the more expansive
semantics used by IsSystemRelation/Class.
Also improve the comments in catalog.c.
There are a few remaining places in replication-related code that are
special-casing OIDs below FirstNormalObjectId. I'm inclined to think
those are wrong too, and if there should be any special case it should
just extend to FirstBootstrapObjectId. But first we need to debate
whether a FOR ALL TABLES publication should include information_schema.
Discussion: https://postgr.es/m/21697.1557092753@sss.pgh.pa.us
Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us M contrib/sepgsql/dml.c
M src/backend/access/transam/varsup.c
M src/backend/catalog/catalog.c
M src/backend/catalog/heap.c
M src/backend/catalog/pg_publication.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/utils/cache/relcache.c
M src/include/catalog/catalog.h
Fix error status of vacuumdb when multiple jobs are used
commit : 3ae3c18b362817f9412c380539f1a16c7abb79c9
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 9 May 2019 10:29:10 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 9 May 2019 10:29:10 +0900 When running a batch of VACUUM or ANALYZE commands on a given database,
there were cases where it is possible to have vacuumdb not report an
error where it actually should, leading to incorrect status results.
Author: Julien Rouhaud
Reviewed-by: Amit Kapila, Michael Paquier
Discussion: https://postgr.es/m/CAOBaU_ZuTwz7CtqLYJ1Ouuh272bTQPLN8b1bAPk0bCBm4PDMTQ@mail.gmail.com
Backpatch-through: 9.5 M src/bin/scripts/vacuumdb.c
Remove obsolete nbtree split REDO routine comment.
commit : d95e36dc384e3068ae2db909c228b1800737b18d
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 8 May 2019 12:47:20 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 8 May 2019 12:47:20 -0700 Commit dd299df8189, which added suffix truncation to nbtree, simplified
the WAL record format used by page splits. It became necessary to
explicitly WAL-log the new high key for the left half of a split in all
cases, which relieved the REDO routine from having to reconstruct a new
high key for the left page by copying the first item from the right
page. Remove a comment that referred to the previous practice. M src/backend/access/nbtree/nbtxlog.c
Fix error messages
commit : 61639816b870347677e6e6945604e0d9da1837ca
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 8 May 2019 13:16:54 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 8 May 2019 13:16:54 -0400 Some messages related to foreign servers were reporting the server name
without quotes, or not at all; our style is to have all names be quoted,
and the server name already appears quoted in a few other messages, so
just add quotes and make them all consistent.
Remove an extra "s" in other messages (typos introduced by myself in
f56f8f8da6af). M src/backend/commands/foreigncmds.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_data.out
Fix documentation for the privileges required for replication functions.
commit : df631ebc737e9d9cdf8d0691969d404f1bd584a4
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 9 May 2019 01:35:13 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 9 May 2019 01:35:13 +0900 Previously it's documented that use of replication functions is
restricted to superusers. This is true for the functions which
use replication origin, but not for pg_logicl_emit_message() and
functions which use replication slot. For example, not only
superusers but also users with REPLICATION privilege is allowed
to use the functions for replication slot. This commit fixes
the documentation for the privileges required for those replication
functions.
Back-patch to 9.4 (all supported versions).
Author: Matsumura Ryo
Discussion: https://postgr.es/m/03040DFF97E6E54E88D3BFEE5F5480F74ABA6E16@G01JPEXMBYT04 M doc/src/sgml/func.sgml
Fix table lock levels for REINDEX INDEX CONCURRENTLY
commit : add85ead4ab969c1e31d64f4476c2335856f4aa9
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 8 May 2019 14:15:01 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 8 May 2019 14:15:01 +0200 REINDEX CONCURRENTLY locks tables with ShareUpdateExclusiveLock rather
than the ShareLock used by a plain REINDEX. However,
RangeVarCallbackForReindexIndex() was not updated for that and still
used the ShareLock only. This would lead to lock upgrades later,
leading to possible deadlocks.
Reported-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://www.postgresql.org/message-id/flat/20190430151735.wi52sxjvxsjvaxxt%40alap3.anarazel.de M src/backend/commands/indexcmds.c
Probe only 127.0.0.1 when looking for ports on Unix.
commit : 8efe710d9c84502b3e6a9487937bccf881f56d9c
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 6 May 2019 15:02:41 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 6 May 2019 15:02:41 +1200 Commit c0985099, later adjusted by commit 4ab02e81, probed 0.0.0.0
in addition to 127.0.0.1, for the benefit of Windows build farm
animals. It isn't really useful on Unix systems, and turned out to
be a bit inconvenient to users of some corporate firewall software.
Switch back to probing just 127.0.0.1 on non-Windows systems.
Back-patch to 9.6, like the earlier changes.
Discussion: https://postgr.es/m/CA%2BhUKG%2B21EPwfgs4m%2BtqyRtbVqkOUvP8QQ8sWk9%2Bh55Aub1H3A%40mail.gmail.com M src/test/perl/PostgresNode.pm
Fix copy-and-paste mistakes in documentation.
commit : 098344be663f5fc0ad166e7a9e1cd37721ee34d9
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 8 May 2019 21:14:14 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 8 May 2019 21:14:14 +1200 Reported-by: Vik Fearing M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/ref/create_table_as.sgml
Add missing periods to comments.
commit : b7434dc007252d7a5e5f7f85700bd7400b1db201
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 8 May 2019 16:49:09 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 8 May 2019 16:49:09 +0900 M src/include/nodes/pathnodes.h
Remove leftover reference to old “flat file” mechanism in a comment.
commit : 256be1050cbbf90b1e44d11c8ed10f98255aa27d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 8 May 2019 09:32:34 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 8 May 2019 09:32:34 +0300 The flat file mechanism was removed in PostgreSQL 9.0. M src/backend/access/transam/xact.c
Correct obsolete nbtsort.c minimum key comment.
commit : d65b5ccad626e1942c862e8a70f56ad7ee7a8003
author : Peter Geoghegan <pg@bowt.ie>
date : Tue, 7 May 2019 21:42:12 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Tue, 7 May 2019 21:42:12 -0700 It is no longer possible under any circumstances for nbtree code to
reconstruct a strict lower bound key (parent page's pivot tuple key) for
a right sibling page by retrieving the first item in the right sibling
page. M src/backend/access/nbtree/nbtsort.c
Add jsonpath_encoding_1.out changes missed in 29ceacc3f9
commit : e5f978631722bb3cac42f0eb6e65e947e0f088ec
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 8 May 2019 01:55:31 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 8 May 2019 01:55:31 +0300 Reported-by: Tom Lane
Discussion: https://postgr.es/m/14305.1557268259%40sss.pgh.pa.us M src/test/regress/expected/jsonpath_encoding_1.out
Remove word “singleton” out of jsonpath docs
commit : 53ae0b16d6f60a15427e081091b2b81e36e674ee
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 30 Apr 2019 01:12:05 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 30 Apr 2019 01:12:05 +0300 Word "singleton" is hard for user understanding, especially taking into account
there is only one place it's used in the docs and there is even no definition.
Use more evident wording instead.
Discussion: https://postgr.es/m/23737.1556550645%40sss.pgh.pa.us M doc/src/sgml/func.sgml
Improve error reporting in jsonpath
commit : 29ceacc3f93720d3ebb7e7e999f8b7fe9622389c
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 23 Apr 2019 17:43:09 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 23 Apr 2019 17:43:09 +0300 This commit contains multiple improvements to error reporting in jsonpath
including but not limited to getting rid of following things:
* definition of error messages in macros,
* errdetail() when valueable information could fit to errmsg(),
* word "singleton" which is not properly explained anywhere,
* line breaks in error messages.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/14890.1555523005%40sss.pgh.pa.us
Author: Alexander Korotkov
Reviewed-by: Tom Lane M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/adt/jsonpath_gram.y
M src/backend/utils/adt/jsonpath_scan.l
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/expected/jsonpath.out
M src/test/regress/expected/jsonpath_encoding.out
M src/test/regress/expected/jsonpath_encoding_1.out
Add TRUNCATE parameter to VACUUM.
commit : b84dbc8eb80b43e554891c459a19969d9fbdefe5
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 8 May 2019 02:10:33 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 8 May 2019 02:10:33 +0900 This commit adds new parameter to VACUUM command, TRUNCATE,
which specifies that VACUUM should attempt to truncate off
any empty pages at the end of the table and allow the disk space
for the truncated pages to be returned to the operating system.
This parameter, if specified, overrides the vacuum_truncate
reloption. If neither the reloption nor the VACUUM option is
used, the default is true, as before.
Author: Fujii Masao
Reviewed-by: Julien Rouhaud, Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoD+qtrSDL=GSma4Wd3kLYLeRC0hPna-YAdkDeV4z156vg@mail.gmail.com M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/ref/vacuum.sgml
M src/backend/access/heap/vacuumlazy.c
M src/backend/commands/vacuum.c
M src/backend/postmaster/autovacuum.c
M src/bin/psql/tab-complete.c
M src/include/commands/vacuum.h
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Fix typos and clarify a comment
commit : 98719af6c2e30d538cd05cfe044f58ba4067b52b
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 7 May 2019 18:26:09 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 7 May 2019 18:26:09 +0200 Author: Daniel Gustafsson <daniel@yesql.se> M src/backend/utils/adt/jsonpath_exec.c
Avoid “invalid memory alloc request size” while reading pg_stat_activity.
commit : 8d0ddccec6366a2851da7d350b33659203aa644b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 May 2019 11:41:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 May 2019 11:41:37 -0400 On a 64-bit machine, if you set track_activity_query_size and
max_connections such that their product exceeds 1GB, shared memory
setup will still succeed (given enough RAM), but attempts to read
pg_stat_activity fail with "invalid memory alloc request size".
Work around that by using MemoryContextAllocHuge to allocate the
local copy of the activity strings. Using the "huge" API costs us
nothing extra in normal cases, and it seems better than throwing
an error and/or explaining to people why they can't do this.
This situation seems insanely profligate today, but who knows what
people will consider normal in ten or twenty years? So let's fix it
in HEAD but not worry about a back-patch.
Per report from James Tomson.
Discussion: https://postgr.es/m/1CFDCCD6-B268-48D8-85C8-400D2790B2C3@pushd.com M src/backend/postmaster/pgstat.c
doc: Generate keywords table automatically
commit : b753bc0c84e51c200ec7de6cefb6f689d13fef62
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 7 May 2019 15:29:39 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 7 May 2019 15:29:39 +0200 The SQL keywords table in the documentation had until now been
generated by some ad hoc scripting outside the source tree once for
each major release. This changes it to an automated process.
We have the PostgreSQL keywords available in a parseable format in
parser/kwlist.h. For the relevant SQL standard versions, keep the
keyword lists in new text files. A new script
generate-keywords-table.pl pulls it all together and produces a
DocBook table.
The final output in the documentation should be identical after this
change.
Discussion: https://www.postgresql.org/message-id/flat/07daeadd-8c82-0d95-5e19-e350502cb749%402ndquadrant.com M doc/src/sgml/.gitignore
M doc/src/sgml/Makefile
M doc/src/sgml/filelist.sgml
A doc/src/sgml/generate-keywords-table.pl
M doc/src/sgml/keywords.sgml
A doc/src/sgml/keywords/sql1992-nonreserved.txt
A doc/src/sgml/keywords/sql1992-reserved.txt
A doc/src/sgml/keywords/sql2008-02-nonreserved.txt
A doc/src/sgml/keywords/sql2008-02-reserved.txt
A doc/src/sgml/keywords/sql2008-09-nonreserved.txt
A doc/src/sgml/keywords/sql2008-09-reserved.txt
A doc/src/sgml/keywords/sql2008-14-nonreserved.txt
A doc/src/sgml/keywords/sql2008-14-reserved.txt
A doc/src/sgml/keywords/sql2011-02-nonreserved.txt
A doc/src/sgml/keywords/sql2011-02-reserved.txt
A doc/src/sgml/keywords/sql2011-09-nonreserved.txt
A doc/src/sgml/keywords/sql2011-09-reserved.txt
A doc/src/sgml/keywords/sql2011-14-nonreserved.txt
A doc/src/sgml/keywords/sql2011-14-reserved.txt
Revert “Avoid the creation of the free space map for small heap relations”.
commit : 7db0cde6b58eef2ba0c70437324cbc7622230320
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 7 May 2019 09:30:24 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 7 May 2019 09:30:24 +0530 This feature was using a process local map to track the first few blocks
in the relation. The map was reset each time we get the block with enough
freespace. It was discussed that it would be better to track this map on
a per-relation basis in relcache and then invalidate the same whenever
vacuum frees up some space in the page or when FSM is created. The new
design would be better both in terms of API design and performance.
List of commits reverted, in reverse chronological order:
06c8a5090e Improve code comments in b0eaa4c51b.
13e8643bfc During pg_upgrade, conditionally skip transfer of FSMs.
6f918159a9 Add more tests for FSM.
9c32e4c350 Clear the local map when not used.
29d108cdec Update the documentation for FSM behavior..
08ecdfe7e5 Make FSM test portable.
b0eaa4c51b Avoid creation of the free space map for small heap relations.
Discussion: https://postgr.es/m/20190416180452.3pm6uegx54iitbt5@alap3.anarazel.de M contrib/pageinspect/expected/page.out
M contrib/pageinspect/sql/page.sql
M contrib/pgstattuple/pgstatapprox.c
M doc/src/sgml/pgfreespacemap.sgml
M doc/src/sgml/pgstattuple.sgml
M doc/src/sgml/ref/pgupgrade.sgml
M doc/src/sgml/storage.sgml
M src/backend/access/brin/brin.c
M src/backend/access/brin/brin_pageops.c
M src/backend/access/heap/hio.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/access/transam/xact.c
M src/backend/storage/freespace/README
M src/backend/storage/freespace/freespace.c
M src/backend/storage/freespace/indexfsm.c
M src/bin/pg_upgrade/info.c
M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pg_upgrade/relfilenode.c
M src/include/storage/freespace.h
D src/test/regress/expected/fsm.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
D src/test/regress/sql/fsm.sql
Remove some code related to 7.3 and older servers from tools of src/bin/
commit : af82f95abb23a56d18fd009ef9eca68ef803a041
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 7 May 2019 09:39:39 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 7 May 2019 09:39:39 +0900 This code was broken as of 582edc3, and is most likely not used anymore.
Note that pg_dump supports servers down to 8.0, and psql has code to
support servers down to 7.4.
Author: Julien Rouhaud
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/CAOBaU_Y5y=zo3+2gf+2NJC1pvMYPcbRXoQaPXx=U7+C8Qh4CzQ@mail.gmail.com M src/bin/scripts/common.c
docs: fist draft version of the PG 12 release notes
commit : bdf595adbca195fa54a909c74a5233ebc30641a1
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 6 May 2019 19:02:34 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 6 May 2019 19:02:34 -0400 Still needs text markup, links, word wrap, and indenting. M doc/src/sgml/release-12.sgml
Revert “Make pg_dump emit ATTACH PARTITION instead of PARTITION OF”
commit : a1ec7402e9a0392f95bc79542af0efcd5c6e7929
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 6 May 2019 12:23:49 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 6 May 2019 12:23:49 -0400 ... and fallout (from branches 10, 11 and master). The change was
ill-considered, and it broke a few normal use cases; since we don't have
time to fix it, we'll try again after this week's minor releases.
Reported-by: Rushabh Lathia
Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
Add tests for error message generation in partition tuple routing
commit : 91248608a61d5504f8ac46534136de9b3717fed2
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 6 May 2019 21:44:24 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 6 May 2019 21:44:24 +0900 This adds extra tests for the error message generated for partition
tuple routing in the executor, using more than three levels of
partitioning including partitioned tables with no partitions. These
tests have been added to fix CVE-2019-10129 on REL_11_STABLE. HEAD has
no active bugs in this area, but it lacked coverage.
Author: Michael Paquier
Reviewed-by: Noah Misch
Security: CVE-2019-10129 M src/test/regress/expected/insert.out
M src/test/regress/sql/insert.sql
Use checkAsUser for selectivity estimator checks, if it’s set.
commit : a0905056fd6b0927dd33f185adc9e7503515fc0d
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 11:54:32 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 11:54:32 +0100 In examine_variable() and examine_simple_variable(), when checking the
user's table and column privileges to determine whether to grant
access to the pg_statistic data, use checkAsUser for the privilege
checks, if it's set. This will be the case if we're accessing the
table via a view, to indicate that we should perform privilege checks
as the view owner rather than the current user.
This change makes this planner check consistent with the check in the
executor, so the planner will be able to make use of statistics if the
table is accessible via the view. This fixes a performance regression
introduced by commit e2d4ef8de8, which affects queries against
non-security barrier views in the case where the user doesn't have
privileges on the underlying table, but the view owner does.
Note that it continues to provide the same safeguards controlling
access to pg_statistic for direct table access (in which case
checkAsUser won't be set) and for security barrier views, because of
the nearby checks on rte->security_barrier and rte->securityQuals.
Back-patch to all supported branches because e2d4ef8de8 was.
Dean Rasheed, reviewed by Jonathan Katz and Stephen Frost. M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql
Fix security checks for selectivity estimation functions with RLS.
commit : 1aebfbea83c4a3e1a0aba4b0910135dc5a45666c
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 11:38:43 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 11:38:43 +0100 In commit e2d4ef8de8, security checks were added to prevent
user-supplied operators from running over data from pg_statistic
unless the user has table or column privileges on the table, or the
operator is leakproof. For a table with RLS, however, checking for
table or column privileges is insufficient, since that does not
guarantee that the user has permission to view all of the column's
data.
Fix this by also checking for securityQuals on the RTE, and insisting
that the operator be leakproof if there are any. Thus the
leakproofness check will only be skipped if there are no securityQuals
and the user has table or column privileges on the table -- i.e., only
if we know that the user has access to all the data in the column.
Back-patch to 9.5 where RLS was added.
Dean Rasheed, reviewed by Jonathan Katz and Stephen Frost.
Security: CVE-2019-10130 M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Bring pg_nextoid()’s error messages into line with message style guide.
commit : bd5e8b627bae9e394352a388d2ad30465eafea2c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 17:06:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 17:06:53 -0400 Noticed while reviewing nearby code. Given all the disclaimers about
this not being meant as user-facing code, I wonder whether we should
make these non-translatable? But in any case there's little excuse
for them not to be good English. M src/backend/catalog/catalog.c
Fix style violations in syscache lookups.
commit : 9691aa72e2a7fb146ac759e1f8a8b04962128cc0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 13:10:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 13:10:07 -0400 Project style is to check the success of SearchSysCacheN and friends
by applying HeapTupleIsValid to the result. A tiny minority of calls
creatively did it differently. Bring them into line with the rest.
This is just cosmetic, since HeapTupleIsValid is indeed just a null
check at the moment ... but that may not be true forever, and in any
case it puts a mental burden on readers who may wonder why these
call sites are not like the rest.
Back-patch to v11 just to keep the branches in sync. (The bulk of these
errors seem to have originated in v11 or v12, though a few are old.)
Per searching to see if anyplace else had made the same error
repaired in 62148c352. M src/backend/catalog/partition.c
M src/backend/catalog/pg_publication.c
M src/backend/commands/indexcmds.c
M src/backend/commands/opclasscmds.c
M src/backend/commands/operatorcmds.c
M src/backend/commands/statscmds.c
M src/backend/commands/tablecmds.c
M src/backend/optimizer/util/appendinfo.c
M src/backend/optimizer/util/plancat.c
Add check for syscache lookup failure in update_relispartition().
commit : 62148c3520b562e518f17134b22120bab0cb113b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 12:44:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 12:44:32 -0400 Omitted in commit 05b38c7e6 (though it looks like the original blame
belongs to 9e9befac4). A failure is admittedly unlikely, but if it
did happen, SIGSEGV is not the approved method of reporting it.
Per Coverity. Back-patch to v11 where the broken code originated. M src/backend/commands/indexcmds.c
Fix set of issues with memory-allocation system calls in frontend code
commit : 84e4570da9230d45022ef77f98b560f26eaf6916
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 4 May 2019 16:32:19 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 4 May 2019 16:32:19 +0900 Like the backend, the frontend has wrappers on top of malloc() and such
whose use is recommended. Particularly, it is possible to do memory
allocation without issuing an error. Some binaries missed the use of
those wrappers, so let's fix the gap for consistency.
This also fixes two latent bugs:
- In pg_dump/pg_dumpall when parsing an ACL item, on an out-of-memory
error for strdup(), the code considered the failure as a ACL parsing
problem instead of an actual OOM.
- In pg_waldump, an OOM when building the target directory string would
cause a crash.
Author: Daniel Gustafsson
Discussion: https://postgr.es/m/gY0y9xenfoBPc-Tufsr2Zg-MmkrJslm0Tw_CMg4p_j58-k_PXNC0klMdkKQkg61BkXC9_uWo-DcUzfxnHqpkpoR5jjVZrPHqKYikcHIiONhg=@yesql.se M src/bin/pg_ctl/pg_ctl.c
M src/bin/pg_dump/dumputils.c
M src/bin/pg_test_fsync/pg_test_fsync.c
M src/bin/pg_waldump/pg_waldump.c
M src/bin/psql/large_obj.c
MSVC: Build ~35% faster by calling dumpbin just once per directory.
commit : 34ff542a71f8e8e768b24d40548dec4be0c707c3
author : Noah Misch <noah@leadboat.com>
date : Fri, 3 May 2019 21:56:47 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 3 May 2019 21:56:47 -0700 Peifeng Qiu
Discussion: https://postgr.es/m/CABmtVJiKXQjast0dQD-8KAtfm8XmyYxo-4Dc7+M+fBr8JRTqkw@mail.gmail.com M src/tools/msvc/gendef.pl
Suppress compiler warning in non-SSL, non-assert builds.
commit : 726cc4242a2f766c8280a72ef7c8418965d139c8
author : Noah Misch <noah@leadboat.com>
date : Fri, 3 May 2019 21:56:46 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 3 May 2019 21:56:46 -0700 Jeff Janes, reviewed by Michael Paquier.
Discussion: https://postgr.es/m/CAMkU=1x8taZfsbPkv_MsWbTtzibW_yQHXoMhF_DTtm=z2hVHDg@mail.gmail.com M contrib/pgcrypto/imath.c
Correct more obsolete nbtree page split comments.
commit : 7b37f4b02e11813b3cd9f7086149ba962a91e03c
author : Peter Geoghegan <pg@bowt.ie>
date : Fri, 3 May 2019 13:34:45 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Fri, 3 May 2019 13:34:45 -0700 Commit 3f342839 corrected obsolete comments about buffer locks at the
main _bt_insert_parent() call site, but missed similar obsolete comments
above _bt_insert_parent() itself. Both sets of comments were rendered
obsolete by commit 40dae7ec537, which made the nbtree page split
algorithm more robust. Fix the comments that were missed the first time
around now.
In passing, refine a related _bt_insert_parent() comment about
re-finding the parent page to insert new downlink. M src/backend/access/nbtree/nbtinsert.c
Doc: remove obsolete comment about per-branch documentation.
commit : 8309eae499d6782bfc5e81f4d1cfcbf8e3fc8f5d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 May 2019 12:32:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 May 2019 12:32:06 -0400 I should have removed this in a0b762626, but forgot. M doc/src/sgml/release.sgml
Remove RelationSetIndexList().
commit : f884dca4959f64bd47e78102d1dadd2c77d49201
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 May 2019 10:26:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 May 2019 10:26:14 -0400 In the wake of commit f912d7dec, RelationSetIndexList isn't used any
more. It was always a horrid wart, so getting rid of it is very nice.
We can also convert rd_indexvalid back to a plain boolean.
Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us M src/backend/utils/cache/relcache.c
M src/include/utils/rel.h
M src/include/utils/relcache.h
Fix reindexing of pg_class indexes some more.
commit : f912d7dec29341d55315fccef8dc3fdfd068c6e3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 May 2019 19:11:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 May 2019 19:11:28 -0400 Commits 3dbb317d3 et al failed under CLOBBER_CACHE_ALWAYS testing.
Investigation showed that to reindex pg_class_oid_index, we must
suppress accesses to the index (via SetReindexProcessing) before we call
RelationSetNewRelfilenode, or at least before we do CommandCounterIncrement
therein; otherwise, relcache reloads happening within the CCI may try to
fetch pg_class rows using the index's new relfilenode value, which is as
yet an empty file.
Of course, the point of 3dbb317d3 was that that ordering didn't work
either, because then RelationSetNewRelfilenode's own update of the index's
pg_class row cannot access the index, should it need to.
There are various ways we might have got around that, but Andres Freund
came up with a brilliant solution: for a mapped index, we can really just
skip the pg_class update altogether. The only fields it was actually
changing were relpages etc, but it was just setting them to zeroes which
is useless make-work. (Correct new values will be installed at the end
of index build.) All pg_class indexes are mapped and probably always will
be, so this eliminates the problem by removing work rather than adding it,
always a pleasant outcome. Having taught RelationSetNewRelfilenode to do
it that way, we can revert the code reordering in reindex_index. (But
I left the moved setup code where it was; there seems no reason why it
has to run without use of the old index. If you're trying to fix a
busted pg_class index, you'll have had to disable system index use
altogether to get this far.)
Moreover, this means we don't need RelationSetIndexList at all, because
reindex_relation's hacking to make "REINDEX TABLE pg_class" work is
likewise now unnecessary. We'll leave that code in place in the back
branches, but a follow-on patch will remove it in HEAD.
In passing, do some minor cleanup for commit 5c1560606 (in HEAD only),
notably removing a duplicate newrnode assignment.
Patch by me, using a core idea due to Andres Freund. Back-patch to all
supported branches, as 3dbb317d3 was.
Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us M src/backend/catalog/index.c
M src/backend/utils/cache/relcache.c
heap_prepare_freeze_tuple: Simplify coding
commit : 2bf372a4ae26337ee61cf7a82081cf4bed05182d
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 2 May 2019 16:13:48 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 2 May 2019 16:13:48 -0400 Commit d2599ecfcc74 introduced some contorted, confused code around:
readers would think that it's possible for HeapTupleHeaderGetXmin return
a non-frozen value for some frozen tuples, which would be disastrous.
There's no actual bug, but it seems better to make it clearer.
Per gripe from Tom Lane and Andres Freund.
Discussion: https://postgr.es/m/30116.1555430496@sss.pgh.pa.us M src/backend/access/heap/heapam.c
Fix nbtsort.c’s page space accounting.
commit : 6dd86c269d5b9a176f6c9f67ea61cc17fef9d860
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 2 May 2019 12:33:35 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 2 May 2019 12:33:35 -0700 Commit dd299df8189, which made heap TID a tiebreaker nbtree index
column, introduced new rules on page space management to make suffix
truncation safe. In general, suffix truncation needs to have a small
amount of extra space available on the new left page when splitting a
leaf page. This is needed in case it turns out that truncation cannot
even "truncate away the heap TID column", resulting in a
larger-than-firstright leaf high key with an explicit heap TID
representation.
Despite all this, CREATE INDEX/nbtsort.c did not account for the
possible need for extra heap TID space on leaf pages when deciding
whether or not a new item could fit on current page. This could lead to
"failed to add item to the index page" errors when CREATE
INDEX/nbtsort.c tried to finish off a leaf page that lacked space for a
larger-than-firstright leaf high key (it only had space for firstright
tuple, which was just short of what was needed following "truncation").
Several conditions needed to be met all at once for CREATE INDEX to
fail. The problem was in the hard limit on what will fit on a page,
which tends to be masked by the soft fillfactor-wise limit. The easiest
way to recreate the problem seems to be a CREATE INDEX on a low
cardinality text column, with tuples that are of non-uniform width,
using a fillfactor of 100.
To fix, bring nbtsort.c in line with nbtsplitloc.c, which already
pessimistically assumes that all leaf page splits will have high keys
that have a heap TID appended.
Reported-By: Andreas Joseph Krogh
Discussion: https://postgr.es/m/VisenaEmail.c5.3ee7fe277d514162.16a6d785bea@tc7-visena M src/backend/access/nbtree/nbtsort.c
Fix some problems with VACUUM (INDEX_CLEANUP FALSE).
commit : dd69597988859c51131e0cbff3e30432db4259e1
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 2 May 2019 10:07:13 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 2 May 2019 10:07:13 -0400 The new nleft_dead_tuples and nleft_dead_itemids fields are confusing
and do not seem like the correct way forward. One of them is tested
via an assertion that can fail, as it has already done on buildfarm
member topminnow. Remove the assertion and the fields.
Change the logic for the case where a tuple is not initially pruned
by heap_page_prune but later diagnosed HEAPTUPLE_DEAD by
HeapTupleSatisfiesVacuum. Previously, tupgone = true was set in
that case, which leads to treating the tuple as one that will be
removed. In a normal vacuum, that's OK, because we'll remove
index entries for it and then the second heap pass will remove the
tuple itself, but when index cleanup is disabled, those things
don't happen, so we must instead treat it as a recently-dead
tuple that we have voluntarily chosen to keep.
Report and analysis by Tom Lane. This patch loosely based on one
from Masahiko Sawada, but I changed most of it. M src/backend/access/heap/vacuumlazy.c
doc: clarify behavior of pg_upgrade’s clone mode
commit : 26950273dc27ec7775029cffe1140165f942325d
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 1 May 2019 09:09:28 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 1 May 2019 09:09:28 -0400 Be more precise about the benefits of using clone mode. M doc/src/sgml/ref/pgupgrade.sgml
Fix union for pgstat message types
commit : 659e53498c3c04e4f400323c02bef98fe8d13ec8
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 1 May 2019 12:30:44 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 1 May 2019 12:30:44 +0200 The message type for temp files and for checksum failures were missing
from the union. Due to the coding style used there was no compiler error
when this happend. So change the code to actively use the union thereby
producing a compiler error if the same mistake happens again, suggested
by Tom Lane.
Author: Julien Rouhaud
Reported-By: Tomas Vondra
Discussion: https://postgr.es/m/20190430163328.zd4rrlnbvgaqlcdz@development M src/backend/postmaster/pgstat.c
M src/include/pgstat.h
Run catalog reindexing test from 3dbb317d32 serially, to avoid deadlocks.
commit : 809c9b48f4bdd11dfc088f6d0b9a6c57936c32ca
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700 The tests turn out to cause deadlocks in some circumstances. Fairly
reproducibly so with -DRELCACHE_FORCE_RELEASE
-DCATCACHE_FORCE_RELEASE. Some of the deadlocks may be hard to fix
without disproportionate measures, but others probably should be fixed
- but not in 12.
We discussed removing the new tests until we can fix the issues
underlying the deadlocks, but results from buildfarm animal
markhor (which runs with CLOBBER_CACHE_ALWAYS) indicates that there
might be a more severe, as of yet undiagnosed, issue (including on
stable branches) with reindexing catalogs. The failure is:
ERROR: could not read block 0 in file "base/16384/28025": read only 0 of 8192 bytes
Therefore it seems advisable to keep the tests.
It's not certain that running the tests in isolation removes the risk
of deadlocks. It's possible that additional locks are needed to
protect against a concurrent auto-analyze or such.
Per discussion with Tom Lane.
Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us
Backpatch: 9.4-, like 3dbb317d3 M src/test/regress/expected/create_index.out
A src/test/regress/expected/reindex_catalog.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/create_index.sql
A src/test/regress/sql/reindex_catalog.sql
Fix unused variable compiler warning in !debug builds.
commit : 4b40d40b30ae04ba524cd410f14e64ae4425a180
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700 Introduced in 3dbb317d3. Fix by using the new local variable in more
places.
Reported-By: Bruce Momjian (off-list)
Backpatch: 9.4-, like 3dbb317d3 M src/backend/catalog/indexing.c
docs: Fix small copy & paste mistake.
commit : b06a354e381d30e13cef28904bb923896aa4719b
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 16:18:35 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 16:18:35 -0700 Author: Justin Pryzby
Discussion: https://postgr.es/m/20190418005115.r4mat75wvlski3ij@alap3.anarazel.de M doc/src/sgml/ref/insert.sgml
Improve comment spelling and style in llvmjit_deform.c.
commit : a0b5bb6e026a3acf739843b744f3b14d4093450a
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 16:13:54 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 16:13:54 -0700 Author: Justin Pryzby
Discussion:
https://postgr.es/m/20190408141828.GE10080@telsasoft.com
https://postgr.es/m/20181127184133.GM10913@telsasoft.com M src/backend/jit/llvm/llvmjit_deform.c
Improve code inferring length of bitmap for JITed tuple deforming.
commit : 3a48005b0049d69b4376e6ae386479ae3d255a11
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 15:55:07 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 15:55:07 -0700 While discussing comment improvements (see next commit) by Justin
Pryzby, Tom complained about a few details of the logic to infer the
length of the NULL bitmap when building the JITed tuple deforming
function. That bitmap allows to avoid checking the tuple header's
natts, a check which often causes a pipeline stall
Improvements:
a) As long as missing columns aren't taken into account, we can
continue to infer the length of the NULL bitmap from NOT NULL
columns following it. Previously we stopped at the first missing
column. It's unlikely to matter much in practice, but the
alternative would have been to document why we stop.
b) For robustness reasons it seems better to also check against
attisdropped - RemoveAttributeById() sets attnotnull to false, but
an additional check is trivial.
c) Improve related comments
Discussion: https://postgr.es/m/20637.1555957068@sss.pgh.pa.us
Backpatch: - M src/backend/jit/llvm/llvmjit_deform.c
Clean up handling of constraint_exclusion and enable_partition_pruning.
commit : e03ff739695cb731956763355e8e0f38c6905008
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 30 Apr 2019 15:03:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 30 Apr 2019 15:03:35 -0400 The interaction of these parameters was a bit confused/confusing,
and in fact v11 entirely misses the opportunity to apply partition
constraints when a partition is accessed directly (rather than
indirectly from its parent).
In HEAD, establish the principle that enable_partition_pruning controls
partition pruning and nothing else. When accessing a partition via its
parent, we do partition pruning (if enabled by enable_partition_pruning)
and then there is no need to consider partition constraints in the
constraint_exclusion logic. When accessing a partition directly, its
partition constraints are applied by the constraint_exclusion logic,
only if constraint_exclusion = on.
In v11, we can't have such a clean division of these GUCs' effects,
partly because we don't want to break compatibility too much in a
released branch, and partly because the clean coding requires
inheritance_planner to have applied partition pruning to a partitioned
target table, which it doesn't in v11. However, we can tweak things
enough to cover the missed case, which seems like a good idea since
it's potentially a performance regression from v10. This patch keeps
v11's previous behavior in which enable_partition_pruning overrides
constraint_exclusion for an inherited target table, though.
In HEAD, also teach relation_excluded_by_constraints that it's okay to use
inheritable constraints when trying to prune a traditional inheritance
tree. This might not be thought worthy of effort given that that feature
is semi-deprecated now, but we have enough infrastructure that it only
takes a couple more lines of code to do it correctly.
Amit Langote and Tom Lane
Discussion: https://postgr.es/m/9813f079-f16b-61c8-9ab7-4363cab28d80@lab.ntt.co.jp
Discussion: https://postgr.es/m/29069.1555970894@sss.pgh.pa.us M doc/src/sgml/config.sgml
M doc/src/sgml/ddl.sgml
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/util/plancat.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
doc: improve PG 12 to_timestamp()/to_date() wording
commit : ad23adc5a169b114f9ff325932cbf2ce1c5e69c1
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 30 Apr 2019 14:06:57 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 30 Apr 2019 14:06:57 -0400 M doc/src/sgml/func.sgml
doc: move “only” to a more appropriate place in the sentence
commit : 345473862571d5b2c63849f6472828bdc5b49320
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 30 Apr 2019 13:44:31 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 30 Apr 2019 13:44:31 -0400 M doc/src/sgml/func.sgml
Message style fixes
commit : 9f8b717a80c59e4a8e8091a8ff6c6f7666a69c33
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 30 Apr 2019 10:00:38 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 30 Apr 2019 10:00:38 -0400 M src/backend/access/table/tableamapi.c
M src/backend/access/transam/twophase.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/utils/misc/guc.c
M src/test/regress/output/tablespace.source
Widen tuple counter variables from long to int64
commit : 9a83afecb7ec6e828b7dbef3133f3dd8b0b4dddb
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 29 Apr 2019 14:15:19 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 29 Apr 2019 14:15:19 -0400 Mistake in ab0dfc961b6a; progress reporting would have wrapped around
for indexes created with more than 2^31 tuples.
Reported-by: Peter Geoghegan
Discussion: https://postgr.es/m/CAH2-Wz=WbNxc5ob5NJ9yqo2RMJ0q4HXDS30GVCobeCvC9A1L9A@mail.gmail.com M src/backend/access/hash/hashsort.c
M src/backend/access/nbtree/nbtsort.c
Fix potential assertion failure when reindexing a pg_class index.
commit : 3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6
author : Andres Freund <andres@anarazel.de>
date : Mon, 29 Apr 2019 19:42:04 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 29 Apr 2019 19:42:04 -0700 When reindexing individual indexes on pg_class it was possible to
either trigger an assertion failure:
TRAP: FailedAssertion("!(!ReindexIsProcessingIndex(((index)->rd_id)))
That's because reindex_index() called SetReindexProcessing() - which
enables an asserts ensuring no index insertions happen into the index
- before calling RelationSetNewRelfilenode(). That not correct for
indexes on pg_class, because RelationSetNewRelfilenode() updates the
relevant pg_class row, which needs to update the indexes.
The are two reasons this wasn't noticed earlier. Firstly the bug
doesn't trigger when reindexing all of pg_class, as reindex_relation
has code "hiding" all yet-to-be-reindexed indexes. Secondly, the bug
only triggers when the the update to pg_class doesn't turn out to be a
HOT update - otherwise there's no index insertion to trigger the
bug. Most of the time there's enough space, making this bug hard to
trigger.
To fix, move RelationSetNewRelfilenode() to before the
SetReindexProcessing() (and, together with some other code, to outside
of the PG_TRY()).
To make sure the error checking intended by SetReindexProcessing() is
more robust, modify CatalogIndexInsert() to check
ReindexIsProcessingIndex() even when the update is a HOT update.
Also add a few regression tests for REINDEXing of system catalogs.
The last two improvements would have prevented some of the issues
fixed in 5c1560606dc4c from being introduced in the first place.
Reported-By: Michael Paquier
Diagnosed-By: Tom Lane and Andres Freund
Author: Andres Freund
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/20190418011430.GA19133@paquier.xyz
Backpatch: 9.4-, the bug is present in all branches M contrib/test_decoding/expected/rewrite.out
M contrib/test_decoding/sql/rewrite.sql
M src/backend/catalog/index.c
M src/backend/catalog/indexing.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Fix several recently introduced issues around handling new relation forks.
commit : 5c1560606dc4c73993fb07f0176b5ec6c515a1b1
author : Andres Freund <andres@anarazel.de>
date : Mon, 29 Apr 2019 19:28:05 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 29 Apr 2019 19:28:05 -0700 Most of these stem from d25f519107 "tableam: relation creation, VACUUM
FULL/CLUSTER, SET TABLESPACE.".
1) To pass data to the relation_set_new_filenode()
RelationSetNewRelfilenode() was made to update RelationData.rd_rel
directly. That's not OK however, as it makes the relcache entries
temporarily inconsistent. Which among other scenarios is a problem
if a REINDEX targets an index on pg_class - the
CatalogTupleUpdate() in RelationSetNewRelfilenode(). Presumably
that was introduced because other places in the code do so - while
those aren't "good practice" they don't appear to be actively
buggy (e.g. because system tables may not be targeted).
I (Andres) should have caught this while reviewing and signficantly
evolving the code in that commit, mea culpa.
Fix that by instead passing in the new RelFileNode as separate
argument to relation_set_new_filenode() and rely on the relcache to
update the catalog entry. Also revert that the
RelationMapUpdateMap() call was changed to immediate, and undo some
other more unnecessary changes.
2) Document that the relation_set_new_filenode cannot rely on the
whole relcache entry to be valid. It might be worthwhile to
refactor the code to never have to rely on that, but given the way
heap_create() is currently coded, that'd be a large change.
3) ATExecSetTableSpace() shouldn't do FlushRelationBuffers() itself. A
table AM might not use shared buffers at all. Move to
index_copy_data() and heapam_relation_copy_data().
4) heapam_relation_set_new_filenode() previously sometimes accessed
rel->rd_rel->relpersistence rather than the `persistence`
argument. Code movement mistake.
5) Previously heapam_relation_set_new_filenode() re-opened the smgr
relation to create the init for, if necesary. Instead have
RelationCreateStorage() return the SMgrRelation and use it to
create the init fork.
6) Add a note about the danger of modifying the relcache directly to
ATExecSetTableSpace() - it's currently not a bug because there's a
check ERRORing for catalog tables.
Regression tests and assertion improvements that together trigger the
bug described in 1) will be added in a later commit, as there is a
related bug on all branches.
Reported-By: Michael Paquier
Diagnosed-By: Tom Lane and Andres Freund
Author: Andres Freund
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/20190418011430.GA19133@paquier.xyz M src/backend/access/heap/heapam_handler.c
M src/backend/catalog/heap.c
M src/backend/catalog/storage.c
M src/backend/commands/tablecmds.c
M src/backend/utils/cache/relcache.c
M src/include/access/tableam.h
M src/include/catalog/storage.h
M src/include/catalog/storage_xlog.h
Remove obsolete _bt_insert_parent() comment.
commit : 9ee7414ed0435d8946d040eb523824f2d71e2418
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 29 Apr 2019 14:14:38 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 29 Apr 2019 14:14:38 -0700 Remove a comment that refers to a coding practice that was fully removed
by commit a8b8f4db, which introduced MarkBufferDirty(). It looks like
the comment was even obsolete before then, since it concerns
write-ordering dependencies with synchronous buffer writes. M src/backend/access/nbtree/nbtinsert.c
In walreceiver, don’t try to do ereport() in a signal handler.
commit : a1a789eb5ac894b4ca4b7742f2dc2d9602116e46
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Apr 2019 12:26:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Apr 2019 12:26:07 -0400 This is quite unsafe, even for the case of ereport(FATAL) where we won't
return control to the interrupted code, and despite this code's use of
a flag to restrict the areas where we'd try to do it. It's possible
for example that we interrupt malloc or free while that's holding a lock
that's meant to protect against cross-thread interference. Then, any
attempt to do malloc or free within ereport() will result in a deadlock,
preventing the walreceiver process from exiting in response to SIGTERM.
We hypothesize that this explains some hard-to-reproduce failures seen
in the buildfarm.
Hence, get rid of the immediate-exit code in WalRcvShutdownHandler,
as well as the logic associated with WalRcvImmediateInterruptOK.
Instead, we need to take care that potentially-blocking operations
in the walreceiver's data transmission logic (libpqwalreceiver.c)
will respond reasonably promptly to the process's latch becoming
set and then call ProcessWalRcvInterrupts. Much of the needed code
for that was already present in libpqwalreceiver.c. I refactored
things a bit so that all the uses of PQgetResult use latch-aware
waiting, but didn't need to do much more.
These changes should be enough to ensure that libpqwalreceiver.c
will respond promptly to SIGTERM whenever it's waiting to receive
data. In principle, it could block for a long time while waiting
to send data too, and this patch does nothing to guard against that.
I think that that hazard is mostly theoretical though: such blocking
should occur only if we fill the kernel's data transmission buffers,
and we don't generally send enough data to make that happen without
waiting for input. If we find out that the hazard isn't just
theoretical, we could fix it by using PQsetnonblocking, but that
would require more ticklish changes than I care to make now.
This is a bug fix, but it seems like too big a change to push into
the back branches without much more testing than there's time for
right now. Perhaps we'll back-patch once we have more confidence
in the change.
Patch by me; thanks to Thomas Munro for review.
Discussion: https://postgr.es/m/20190416070119.GK2673@paquier.xyz M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/backend/replication/walreceiver.c
M src/include/replication/walreceiver.h
Fix some typos
commit : 9c592896d9fc81d8def7b98c89a869588e76f0ea
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 29 Apr 2019 23:52:42 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 29 Apr 2019 23:52:42 +0900 Author: Daniel Gustafsson
Discussion: https://postgr.es/m/42kEeWei6VxLGh12QbR08hiI5Pm-c3XgbK7qj393PSttEhVbnnQoFXHKzXjPRZLUpndWAfHIuZuUqGZBzyXadmEUCSqm9xphWur_I8vESMA=@yesql.se M src/bin/pg_dump/pg_dump.c
M src/bin/pgbench/t/001_pgbench_with_server.pl
Message fixes
commit : ffbce803e646e254367a3f0670d8b64604badc50
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 29 Apr 2019 10:05:07 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 29 Apr 2019 10:05:07 -0400 M src/bin/pg_checksums/pg_checksums.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pg_upgrade/check.c
M src/bin/scripts/vacuumdb.c
Fix potential catalog corruption with temporary identity columns
commit : cd3e27464cca40664c54fb8cd10454f979c1db4e
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 29 Apr 2019 08:44:51 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 29 Apr 2019 08:44:51 +0200 If a temporary table with an identity column and ON COMMIT DROP is
created in a single-statement transaction (not useful, but allowed),
it would leave the catalog corrupted. We need to add a
CommandCounterIncrement() so that PreCommit_on_commit_actions() sees
the created dependency between table and sequence and can clean it
up.
The analogous and more useful case of doing this in a transaction
block already runs some CommandCounterIncrement() before it gets to
the on-commit cleanup, so it wasn't a problem in practical use.
Several locations for placing the new CommandCounterIncrement() call
were discussed. This patch places it at the end of
standard_ProcessUtility(). That would also help if other commands
were to create catalog entries that some on-commit action would like
to see.
Bug: #15631
Reported-by: Serge Latyntsev <dnsl48@gmail.com>
Author: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Reviewed-by: Michael Paquier <michael@paquier.xyz> M src/backend/tcop/utility.c
Do pre-release housekeeping on catalog data, and fix jsonpath send/recv.
commit : c3f67ed6e434333e1bc011afc94c25d9959a86bd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Apr 2019 17:16:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Apr 2019 17:16:50 -0400 Run renumber_oids.pl to move high-numbered OIDs down, as per pre-beta
tasks specified by RELEASE_CHANGES. (The only change is 8394 -> 3428.)
Also run reformat_dat_file.pl while I'm here.
While looking at the reformat diffs, I chanced to notice that type
jsonpath had typsend and typreceive = '-', which surely is not the
intention given that jsonpath_send and jsonpath_recv exist.
Fix that. It's safe to assume that these functions have never been
tested :-(. I didn't try, but somebody should. M src/include/catalog/catversion.h
M src/include/catalog/pg_proc.dat
M src/include/catalog/pg_type.dat
Use preprocessor conditions compatible with Emacs indent.
commit : 90e7f317735159116fdc3f90e287dd688b18a353
author : Noah Misch <noah@leadboat.com>
date : Sun, 28 Apr 2019 12:56:53 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 28 Apr 2019 12:56:53 -0700 Emacs wrongly indented hundreds of subsequent lines. M src/backend/postmaster/postmaster.c
M src/bin/pg_upgrade/controldata.c
Clean up minor warnings from buildfarm.
commit : e481d26285b160058b093588e062cf3071fea192
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Apr 2019 12:45:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Apr 2019 12:45:55 -0400 Be more consistent about use of XXXGetDatum macros in new jsonpath
code. This is mostly to avoid having code that looks randomly
different from everyplace else that's doing the exact same thing.
In pg_regress.c, avoid an unreferenced-function warning from
compilers that don't understand pg_attribute_unused(). Putting
the function inside the same #ifdef as its only caller is more
straightforward coding anyway.
In be-secure-openssl.c, avoid use of pg_attribute_unused() on a label.
That's pretty creative, but there's no good reason to suppose that
it's portable, and there's absolutely no need to use goto's here in the
first place. (This wasn't actually causing any buildfarm complaints,
but it's new code in v12 so it has no portability track record.) M src/backend/libpq/be-secure-openssl.c
M src/backend/utils/adt/jsonpath.c
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/adt/jsonpath_gram.y
M src/test/regress/pg_regress.c
Fix more typos and inconsistencies in documentation
commit : ac862376037727e744f25030bd8b6090c707247b
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 28 Apr 2019 22:53:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 28 Apr 2019 22:53:33 +0900 This fixes a couple of grammar mistakes, typos and inconsistencies in
the documentation. Particularly, the configuration parsing allows only
"kB" to mean kilobyte but there were references in the docs to "KB".
Some instances of the latter are still in the code comments. Some
parameter values were mentioned with "Minus-one", and using directly
"-1" with proper markups is more helpful to the reader.
Some of these have been pointed out by Justin, and some others are
things I bumped into.
Author: Justin Pryzby, Michael Paquier
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/20190330224333.GQ5815@telsasoft.com M doc/src/sgml/auto-explain.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/sources.sgml
Avoid postgres_fdw crash for a targetlist entry that’s just a Param.
commit : 8cad5adb9c0be82e9f40d51b02a542439f47de9e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 27 Apr 2019 13:15:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 27 Apr 2019 13:15:54 -0400 foreign_grouping_ok() is willing to put fairly arbitrary expressions into
the targetlist of a remote SELECT that's doing grouping or aggregation on
the remote side, including expressions that have no foreign component to
them at all. This is possibly a bit dubious from an efficiency standpoint;
but it rises to the level of a crash-causing bug if the expression is just
a Param or non-foreign Var. In that case, the expression will necessarily
also appear in the fdw_exprs list of values we need to send to the remote
server, and then setrefs.c's set_foreignscan_references will mistakenly
replace the fdw_exprs entry with a Var referencing the targetlist result.
The root cause of this problem is bad design in commit e7cb7ee14: it put
logic into set_foreignscan_references that IMV is postgres_fdw-specific,
and yet this bug shows that it isn't postgres_fdw-specific enough. The
transformation being done on fdw_exprs assumes that fdw_exprs is to be
evaluated with the fdw_scan_tlist as input, which is not how postgres_fdw
uses it; yet it could be the right thing for some other FDW. (In the
bigger picture, setrefs.c has no business assuming this for the other
expression fields of a ForeignScan either.)
The right fix therefore would be to expand the FDW API so that the
FDW could inform setrefs.c how it intends to evaluate these various
expressions. We can't change that in the back branches though, and we
also can't just summarily change setrefs.c's behavior there, or we're
likely to break external FDWs.
As a stopgap, therefore, hack up postgres_fdw so that it won't attempt
to send targetlist entries that look exactly like the fdw_exprs entries
they'd produce. In most cases this actually produces a superior plan,
IMO, with less data needing to be transmitted and returned; so we probably
ought to think harder about whether we should ship tlist expressions at
all when they don't contain any foreign Vars or Aggs. But that's an
optimization not a bug fix so I left it for later. One case where this
produces an inferior plan is where the expression in question is actually
a GROUP BY expression: then the restriction prevents us from using remote
grouping. It might be possible to work around that (since that would
reduce to group-by-a-constant on the remote side); but it seems like a
pretty unlikely corner case, so I'm not sure it's worth expending effort
solely to improve that. In any case the right long-term answer is to fix
the API as sketched above, and then revert this hack.
Per bug #15781 from Sean Johnston. Back-patch to v10 where the problem
was introduced.
Discussion: https://postgr.es/m/15781-2601b1002bad087c@postgresql.org M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/postgres_fdw.h
M contrib/postgres_fdw/sql/postgres_fdw.sql
Add viewBox attribute to storage page layout SVG image
commit : 29046c44f36099f4c979b1491fcf27db2f9184f9
author : Joe Conway <mail@joeconway.com>
date : Sat, 27 Apr 2019 11:36:51 -0400
committer: Joe Conway <mail@joeconway.com>
date : Sat, 27 Apr 2019 11:36:51 -0400 Recently added SVG image for storage page layout lacks
a viewBox attribute which seems necessary to ensure propoer
rendering. Add it.
Author: Jonathan Katz
Discussion: https://postgr.es/m/ba31e0e1-4c9b-b309-70e8-8e7ac14fc87e%40postgresql.org M doc/src/sgml/images/pagelayout.svg
Add guidance on making documentation SVG images responsive
commit : 7dc78d8ef3e62f7e06d7767c63dcede048377b9a
author : Joe Conway <mail@joeconway.com>
date : Sat, 27 Apr 2019 11:12:52 -0400
committer: Joe Conway <mail@joeconway.com>
date : Sat, 27 Apr 2019 11:12:52 -0400 Recently added guidance on adding SVG images to the documentation
sources lacks advice on making the images responsive when rendered
in a variety of media types and viewports. Add some.
Patch by Jonathan Katz with some editorialization by me.
Author: Jonathan Katz
Discussion: https://postgr.es/m/6358ae6f-7191-a02b-e7b5-68050636ae71@postgresql.org M doc/src/sgml/images/README
Correct the URL pointing to PL/R
commit : cf3ff97a15c184bf6a665b891f41349c8aba79fb
author : Joe Conway <mail@joeconway.com>
date : Sat, 27 Apr 2019 09:27:56 -0400
committer: Joe Conway <mail@joeconway.com>
date : Sat, 27 Apr 2019 09:27:56 -0400 As pointed out by documentation comment, the URL for PL/R
needs to be updated to the correct current repository. Back-patch
to all supported branches. M doc/src/sgml/external-projects.sgml
Update config.guess and config.sub
commit : ddcaa596725a023c29fce34ff9914e123f225a5e
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 27 Apr 2019 14:25:00 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 27 Apr 2019 14:25:00 +0200 M config/config.guess
M config/config.sub
Portability fix for zic.c.
commit : 48f8fa9ce0f9799c8ae8bcd23c498fe002d5496d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 21:20:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 21:20:11 -0400 Missed an inttypes.h dependency in previous patch. Per buildfarm. M src/timezone/README
M src/timezone/zic.c
Mention REINDEX CONCURRENTLY in documentation about index maintenance
commit : a967878414f906a7f88842424c667a5ac31b9625
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 27 Apr 2019 09:06:39 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 27 Apr 2019 09:06:39 +0900 The documentation includes a section about index maintenance and
reindexing, mentioning a set of steps based on CREATE INDEX CONCURRENTLY
and ALTER TABLE (for constraint dependencies) to emulate REINDEX
CONCURRENTLY. Now that REINDEX CONCURRENTLY is supported, let's just
directly mention it instead.
Reported-by: Peter Geoghegan
Author: Michael Paquier
Reviewed-by: Peter Eisentraut, Tom Lane
Discussion: https://postgr.es/m/CAH2-WzmEL168t6w29aKrKXtpq9-apcmp0HC7K-fKt6ZgLXV6Dg@mail.gmail.com M doc/src/sgml/maintenance.sgml
Sync our copy of the timezone library with IANA release tzcode2019a.
commit : acb897b806a5f4b23784b1c7e395e67b99a4362b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 19:46:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 19:46:26 -0400 This corrects a small bug in zic that caused it to output an incorrect
year-2440 transition in the Africa/Casablanca zone.
More interestingly, zic has grown a "-r" option that limits the range of
zone transitions that it will put into the output files. That might be
useful to people who don't like the weird GMT offsets that tzdb likes
to use for very old dates. It appears that for dates before the cutoff
time specified with -r, zic will use the zone's standard-time offset
as of the cutoff time. So for example one might do
make install ZIC_OPTIONS='-r @-1893456000'
to cause all dates before 1910-01-01 to be treated as though 1910
standard time prevailed indefinitely far back. (Don't blame me for
the unfriendly way of specifying the cutoff time --- it's seconds
since or before the Unix epoch. You can use extract(epoch ...)
to calculate it.)
As usual, back-patch to all supported branches. M src/timezone/Makefile
M src/timezone/README
M src/timezone/private.h
M src/timezone/tzfile.h
M src/timezone/zic.c
Update time zone data files to tzdata release 2019a.
commit : d312de3fc092c784e743e58be4d1617cfb704b71
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 17:56:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 17:56:26 -0400 DST law changes in Palestine and Metlakatla.
Historical corrections for Israel.
Etc/UCT is now a backward-compatibility link to Etc/UTC, instead
of being a separate zone that generates the abbreviation "UCT",
which nowadays is typically a typo. Postgres will still accept
"UCT" as an input zone name, but it won't output it. M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
Update key words table for version 12
commit : 686fef22fdba732aeca28b471a362d4fb5675675
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 26 Apr 2019 23:23:56 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 26 Apr 2019 23:23:56 +0200 M doc/src/sgml/keywords.sgml
Apply stopgap fix for bug #15672.
commit : c01eb619a83aed460b9ead50831265f2acde3c57
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 17:18:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Apr 2019 17:18:07 -0400 Fix DefineIndex so that it doesn't attempt to pass down a to-be-reused
index relfilenode to a child index creation, and fix TryReuseIndex
to not think that reuse is sensible for a partitioned index.
In v11, this fixes a problem where ALTER TABLE on a partitioned table
could assign the same relfilenode to several different child indexes,
causing very nasty catalog corruption --- in fact, attempting to DROP
the partitioned table then leads not only to a database crash, but to
inability to restart because the same crash will recur during WAL replay.
Either of these two changes would be enough to prevent the failure, but
since neither action could possibly be sane, let's put in both changes
for future-proofing.
In HEAD, no such bug manifests, but that's just an accidental consequence
of having changed the pg_class representation of partitioned indexes to
have relfilenode = 0. Both of these changes still seem like smart
future-proofing.
This is only a stop-gap because the code for ALTER TABLE on a partitioned
table with a no-op type change still leaves a great deal to be desired.
As the added regression tests show, it gets things wrong for comments on
child indexes/constraints, and it is regenerating child indexes it doesn't
have to. However, fixing those problems will take more work which may not
get back-patched into v11. We need a fix for the corruption problem now.
Per bug #15672 from Jianing Yang.
Patch by me, regression test cases based on work by Amit Langote,
who also did a lot of the investigative work.
Discussion: https://postgr.es/m/15672-b9fa7db32698269f@postgresql.org M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
pg_dump: store unused attribs as NULL instead of ‘\0’
commit : 7fcdb5e002145ec95b2bebb4c125751be66c4d1a
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Apr 2019 12:03:59 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Apr 2019 12:03:59 -0400 Commit f831d4accda0 changed pg_dump to emit (and pg_restore to
understand) NULLs for unused members in ArchiveEntry structs, as a side
effect of some code beautification. That broke pg_restore of dumps
generated with older pg_dump, however, so it was reverted in
19455c9f5606. Since the archiver version number has been bumped in
3b925e905de3, we can put it back.
Author: Dmitry Dolgov
Discussion: https://postgr.es/m/CA+q6zcXx0XHqLsFJLaUU2j5BDiBAHig=YRoBC_YVq7VJGvzBEA@mail.gmail.com M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_archiver.h
M src/bin/pg_dump/pg_dump.c
doc: Update section on NFS
commit : 60bbf0753e337114d4c7d60dbc5a496b1f464cb5
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 26 Apr 2019 11:50:16 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 26 Apr 2019 11:50:16 +0200 The old section was ancient and didn't seem very helpful. Here, we
add some concrete advice on particular mount options.
Reviewed-by: Joe Conway <mail@joeconway.com>
Discussion: https://www.postgresql.org/message-id/flat/e90f24bb-5423-6abb-58ec-501176eb4afc%402ndquadrant.com M doc/src/sgml/runtime.sgml
Add FDW documentation notes about insert and update tuple routing and COPY.
commit : 90fca7a35aa7ac421f814bdfdf1fee7c30fa82f0
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 26 Apr 2019 18:10:05 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 26 Apr 2019 18:10:05 +0900 Author: Laurenz Albe and Etsuro Fujita
Reviewed-by: Laurenz Albe and Amit Langote
Backpatch-through: 11 where support for that by FDWs was added
Discussion: https://postgr.es/m/bf36a0288e8f31b4f2f40952e225bf892dc1ffc5.camel@cybertec.at M doc/src/sgml/fdwhandler.sgml
Sanitize line pointers within contrib/amcheck.
commit : a9ce839a31375a6c04189222706ae6b2abe96919
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 25 Apr 2019 12:50:37 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 25 Apr 2019 12:50:37 -0700 Adopt a more defensive approach to accessing index tuples in
contrib/amcheck: verify that each line pointer looks sane before
accessing associated tuple using pointer arithmetic based on line
pointer's offset. This avoids undefined behavior and assertion failures
in cases where line pointers are corrupt.
Issue spotted following a complaint about an assertion failure by
Grigory Smolkin, which involved a test harness that deliberately
corrupts indexes.
This is arguably a bugfix, but no backpatch given the lack of field
reports beyond Grigory's.
Discussion: https://postgr.es/m/CAH2-WzmkurhCqnyLHxk0VkOZqd49+ZZsp1xAJOg7j2x7dmp_XQ@mail.gmail.com M contrib/amcheck/verify_nbtree.c
Fix partitioned index attachment
commit : 05b38c7e63d1c8bca8c07ab4c8b194eed3c50ec7
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 25 Apr 2019 10:50:14 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 25 Apr 2019 10:50:14 -0400 When an existing index in a partition is attached to a new index on
its parent, we forgot to set the "relispartition" flag correctly, which
meant that it was not possible to find the index in various operations,
such as adding a foreign key constraint that references that partitioned
table. One of four places that was assigning the parent index was
forgetting to do that, so fix by shifting responsibility of updating the
flag to the routine that changes the parent.
Author: Amit Langote, Álvaro Herrera
Reported-by: Hubert "depesz" Lubaczewski
Discussion: https://postgr.es/m/CA+HiwqHMsRtRYRWYTWavKJ8x14AFsv7bmAV46mYwnfD3vy8goQ@mail.gmail.com M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Fix file path in comment.
commit : c247ae09226eeb1c3a77bb54a0736ed7da5622b5
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 25 Apr 2019 23:49:37 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 25 Apr 2019 23:49:37 +0900 M src/bin/pg_checksums/pg_checksums.c
Fix function names in comments.
commit : 978b032d1f39fcfe9b7e895ab313913d97db2268
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 25 Apr 2019 23:43:48 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 25 Apr 2019 23:43:48 +0900 Commit 3eb77eba5a renamed some functions, but forgot to
update some comments referencing to those functions.
This commit fixes those function names in the comments.
Kyotaro Horiguchi M src/backend/postmaster/checkpointer.c
M src/backend/storage/smgr/md.c
M src/backend/storage/sync/sync.c
M src/common/rmtree.c
Fix tablespace inheritance for partitioned rels
commit : 87259588d0ab0b8e742e30596afa7ae25caadb18
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 25 Apr 2019 10:20:23 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 25 Apr 2019 10:20:23 -0400 Commit ca4103025dfe left a few loose ends. The most important one
(broken pg_dump output) is already fixed by virtue of commit
3b23552ad8bb, but some things remained:
* When ALTER TABLE rewrites tables, the indexes must remain in the
tablespace they were originally in. This didn't work because
index recreation during ALTER TABLE runs manufactured SQL (yuck),
which runs afoul of default_tablespace in competition with the parent
relation tablespace. To fix, reset default_tablespace to the empty
string temporarily, and add the TABLESPACE clause as appropriate.
* Setting a partitioned rel's tablespace to the database default is
confusing; if it worked, it would direct the partitions to that
tablespace regardless of default_tablespace. But in reality it does
not work, and making it work is a larger project. Therefore, throw
an error when this condition is detected, to alert the unwary.
Add some docs and tests, too.
Author: Álvaro Herrera
Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com M doc/src/sgml/config.sgml
M doc/src/sgml/ref/create_table.sgml
M src/backend/bootstrap/bootparse.y
M src/backend/commands/indexcmds.c
M src/backend/commands/matview.c
M src/backend/commands/tablecmds.c
M src/backend/commands/tablespace.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/parser/gram.y
M src/backend/parser/parse_utilcmd.c
M src/backend/utils/adt/ruleutils.c
M src/include/catalog/catversion.h
M src/include/commands/tablespace.h
M src/include/nodes/parsenodes.h
M src/test/regress/input/tablespace.source
M src/test/regress/output/tablespace.source
Make pg_dump emit ATTACH PARTITION instead of PARTITION OF
commit : 3b23552ad8bbb1384381b67f860019d14d5b680e
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 24 Apr 2019 15:30:37 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 24 Apr 2019 15:30:37 -0400 Using PARTITION OF can result in column ordering being changed from the
database being dumped, if the partition uses a column layout different
from the parent's. It's not pg_dump's job to editorialize on table
definitions, so this is not acceptable; back-patch all the way back to
pg10, where partitioned tables where introduced.
This change also ensures that partitions end up in the correct
tablespace, if different from the parent's; this is an oversight in
ca4103025dfe (in pg12 only). Partitioned indexes (in pg11) don't have
this problem, because they're already created as independent indexes and
attached to their parents afterwards.
This change also has the advantage that the partition is restorable from
the dump (as a standalone table) even if its parent table isn't
restored.
Author: David Rowley
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com
Discussion: https://postgr.es/m/20190423185007.GA27954@alvherre.pgsql M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
Fix some minor postmaster-state-machine issues.
commit : 0fae846232148754468f6d57b3f98d5b83d90af7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Apr 2019 14:15:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Apr 2019 14:15:44 -0400 In sigusr1_handler, don't ignore PMSIGNAL_ADVANCE_STATE_MACHINE based
on pmState. The restriction is unnecessary (PostmasterStateMachine
should work in any state), not future-proof (since it makes too many
assumptions about why the signal might be sent), and broken even today
because a race condition can make it necessary to respond to the signal
in PM_WAIT_READONLY state. The race condition seems unlikely, but
if it did happen, a hot-standby postmaster could fail to shut down
after receiving a smart-shutdown request.
In MaybeStartWalReceiver, don't clear the WalReceiverRequested flag
if the fork attempt fails. Leaving it set allows us to try
again in future iterations of the postmaster idle loop. (The startup
process would eventually send a fresh request signal, but this change
may allow us to retry the fork sooner.)
Remove an obsolete comment and unnecessary test in
PostmasterStateMachine's handling of PM_SHUTDOWN_2 state. It's not
possible to have a live walreceiver in that state, and AFAICT has not
been possible since commit 5e85315ea. This isn't a live bug, but the
false comment is quite confusing to readers.
In passing, rearrange sigusr1_handler's CheckPromoteSignal tests so that
we don't uselessly perform stat() calls that we're going to ignore the
results of.
Add some comments clarifying the behavior of MaybeStartWalReceiver;
I very nearly rearranged it in a way that'd reintroduce the race
condition fixed in e5d494d78. Mea culpa for not commenting that
properly at the time.
Back-patch to all supported branches. The PMSIGNAL_ADVANCE_STATE_MACHINE
change is the only one of even minor significance, but we might as well
keep this code in sync across branches.
Discussion: https://postgr.es/m/9001.1556046681@sss.pgh.pa.us M src/backend/postmaster/postmaster.c
Unify error messages
commit : 0a999e1290fc9d8708da61017e732380bc9239a3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 24 Apr 2019 09:26:13 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 24 Apr 2019 09:26:13 -0400 ... for translatability purposes. M src/backend/storage/ipc/latch.c
M src/backend/storage/ipc/signalfuncs.c
M src/backend/utils/adt/formatting.c
M src/backend/utils/adt/genfile.c
M src/backend/utils/adt/json.c
M src/backend/utils/adt/jsonb.c
postgres_fdw: Fix incorrect handling of row movement for remote partitions.
commit : 5c47049180b8977154f99fdc7988d5846764afa2
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 24 Apr 2019 18:31:50 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 24 Apr 2019 18:31:50 +0900 Commit 3d956d9562 added support for update row movement in postgres_fdw.
This patch fixes the following issues introduced by that commit:
* When a remote partition chosen to insert routed rows into was also an
UPDATE subplan target rel that would be updated later, the UPDATE that
used a direct modification plan modified those routed rows incorrectly
because those routed rows were visible to the later UPDATE command.
The right fix for this would be to have some way in postgres_fdw in
which the later UPDATE command ignores those routed rows, but it seems
hard to do so with the current infrastructure. For now throw an error
in that case.
* When a remote partition chosen to insert routed rows into was also an
UPDATE subplan target rel, fmstate created for the UPDATE that used a
non-direct modification plan was mistakenly overridden by another
fmstate created for inserting those routed rows into the partition.
This caused 1) server crash when the partition would be updated later,
and 2) resource leak when the partition had been already updated. To
avoid that, adjust the treatment of the fmstate for the inserting. As
for #1, since we would also have the incorrectness issue as mentioned
above, error out in that case as well.
Update the docs to mention that postgres_fdw currently does not handle
the case where a remote partition chosen to insert a routed row into is
also an UPDATE subplan target rel that will be updated later.
Author: Amit Langote and Etsuro Fujita
Reviewed-by: Amit Langote
Backpatch-through: 11 where row movement in postgres_fdw was added
Discussion: https://postgr.es/m/21e7eaa4-0d4d-20c2-a1f7-c7e96f4ce440@lab.ntt.co.jp M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
M doc/src/sgml/postgres-fdw.sgml
Allow pg_class xid & multixid horizons to not be set.
commit : fdc7efcc30b1da950ade72fd35852c21bf8de839
author : Andres Freund <andres@anarazel.de>
date : Tue, 23 Apr 2019 21:42:12 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 23 Apr 2019 21:42:12 -0700 This allows table AMs that don't need these horizons. This was already
documented in the tableam relation_set_new_filenode callback, but an
assert prevented if from actually working (the test AM code contained
the change itself). Defang the asserts in the general code, and move
the stronger ones into heap AM.
Relatedly, after CLUSTER/VACUUM, we'd always assign a relfrozenxid /
relminmxid. Change the table_relation_copy_for_cluster() interface to
allow the AM to overwrite the horizons that get set on the pg_class
entry. This'd also in the future allow AMs like heap to compute a
relfrozenxid during rewrite that's the table's actual minimum rather
than a pre-determined value. Arguably it'd have been better to move
the whole computation / setting of those values into the callback, but
it seems likely that for other reasons it'd be better to be able to
use one value to vacuum/cluster multiple tables (e.g. a toast's
horizon shouldn't be different than the table's).
Reported-By: Heikki Linnakangas
Author: Andres Freund
Discussion: https://postgr.es/m/9a7fb9cc-2419-5db7-8840-ddc10c93f122@iki.fi M src/backend/access/heap/heapam_handler.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/commands/cluster.c
M src/backend/commands/vacuum.c
M src/backend/postmaster/autovacuum.c
M src/include/access/tableam.h
Repair assorted issues in locale data extraction.
commit : 7ad1cd31bfcbaed122993deb778e6587a226e338
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Apr 2019 18:51:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Apr 2019 18:51:30 -0400 cache_locale_time (extraction of LC_TIME-related info) had never been
taught the lessons we previously learned about extraction of info related
to LC_MONETARY and LC_NUMERIC. Specifically, commit 95a777c61 taught
PGLC_localeconv() that data coming out of localeconv() was in an encoding
determined by the relevant locale, but we didn't realize that there's a
similar issue with strftime(). And commit a4930e7ca hardened
PGLC_localeconv() against errors occurring partway through, but failed
to do likewise for cache_locale_time(). So, rearrange the latter
function to perform encoding conversion and not risk failure while
it's got the locales set to temporary values.
This time around I also changed PGLC_localeconv() to treat it as FATAL
if it can't restore the previous settings of the locale values. There
is no reason (except possibly OOM) for that to fail, and proceeding with
the wrong locale values seems like a seriously bad idea --- especially
on Windows where we have to also temporarily change LC_CTYPE. Also,
protect against the possibility that we can't identify the codeset
reported for LC_MONETARY or LC_NUMERIC; rather than just failing,
try to validate the data without conversion.
The user-visible symptom this fixes is that if LC_TIME is set to a locale
name that implies an encoding different from the database encoding,
non-ASCII localized day and month names would be retrieved in the wrong
encoding, leading to either unexpected encoding-conversion error reports
or wrong output from to_char(). The other possible failure modes are
unlikely enough that we've not seen reports of them, AFAIK.
The encoding conversion problems do not manifest on Windows, since
we'd already created special-case code to handle that issue there.
Per report from Juan José Santamaría Flecha. Back-patch to all
supported versions.
Juan José Santamaría Flecha and Tom Lane
Discussion: https://postgr.es/m/CAC+AXB22So5aZm2vZe+MChYXec7gWfr-n-SK-iO091R0P_1Tew@mail.gmail.com M src/backend/utils/adt/pg_locale.c
M src/test/regress/expected/collate.linux.utf8.out
M src/test/regress/sql/collate.linux.utf8.sql
Remove useless comment.
commit : e0fb4c9d013f8c3f6eb31c5fb991e24b4af6dbb1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Apr 2019 17:17:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Apr 2019 17:17:26 -0400 Commit e439c6f0c removed IndexStmt.relationId, but not the comment
that had been added to explain it. Said comment was therefore
very confusing. M src/include/nodes/parsenodes.h
Prevent O(N^2) unique index insertion edge case.
commit : 9b10926263d831fac5758f1493c929a49b55669b
author : Peter Geoghegan <pg@bowt.ie>
date : Tue, 23 Apr 2019 10:33:57 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Tue, 23 Apr 2019 10:33:57 -0700 Commit dd299df8 made nbtree treat heap TID as a tiebreaker column,
establishing the principle that there is only one correct location (page
and page offset number) for every index tuple, no matter what.
Insertions of tuples into non-unique indexes proceed as if heap TID
(scan key's scantid) is just another user-attribute value, but
insertions into unique indexes are more delicate. The TID value in
scantid must initially be omitted to ensure that the unique index
insertion visits every leaf page that duplicates could be on. The
scantid is set once again after unique checking finishes successfully,
which can force _bt_findinsertloc() to step right one or more times, to
locate the leaf page that the new tuple must be inserted on.
Stepping right within _bt_findinsertloc() was assumed to occur no more
frequently than stepping right within _bt_check_unique(), but there was
one important case where that assumption was incorrect: inserting a
"duplicate" with NULL values. Since _bt_check_unique() didn't do any
real work in this case, it wasn't appropriate for _bt_findinsertloc() to
behave as if it was finishing off a conventional unique insertion, where
any existing physical duplicate must be dead or recently dead.
_bt_findinsertloc() might have to grovel through a substantial portion
of all of the leaf pages in the index to insert a single tuple, even
when there were no dead tuples.
To fix, treat insertions of tuples with NULLs into a unique index as if
they were insertions into a non-unique index: never unset scantid before
calling _bt_search() to descend the tree, and bypass _bt_check_unique()
entirely. _bt_check_unique() is no longer responsible for incoming
tuples with NULL values.
Discussion: https://postgr.es/m/CAH2-Wzm08nr+JPx4jMOa9CGqxWYDQ-_D4wtPBiKghXAUiUy-nQ@mail.gmail.com M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtutils.c
M src/include/access/nbtree.h
Avoid order-of-execution problems with ALTER TABLE ADD PRIMARY KEY.
commit : f4a3fdfbdcd3763c42111318d004c2e90d072021
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Apr 2019 12:25:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Apr 2019 12:25:27 -0400 Up to now, DefineIndex() was responsible for adding attnotnull constraints
to the columns of a primary key, in any case where it hadn't been
convenient for transformIndexConstraint() to mark those columns as
is_not_null. It (or rather its minion index_check_primary_key) did this
by executing an ALTER TABLE SET NOT NULL command for the target table.
The trouble with this solution is that if we're creating the index due
to ALTER TABLE ADD PRIMARY KEY, and the outer ALTER TABLE has additional
sub-commands, the inner ALTER TABLE's operations executed at the wrong
time with respect to the outer ALTER TABLE's operations. In particular,
the inner ALTER would perform a validation scan at a point where the
table's storage might be inconsistent with its catalog entries. (This is
on the hairy edge of being a security problem, but AFAICS it isn't one
because the inner scan would only be interested in the tuples' null
bitmaps.) This can result in unexpected failures, such as the one seen
in bug #15580 from Allison Kaptur.
To fix, let's remove the attempt to do SET NOT NULL from DefineIndex(),
reducing index_check_primary_key's role to verifying that the columns are
already not null. (It shouldn't ever see such a case, but it seems wise
to keep the check for safety.) Instead, make transformIndexConstraint()
generate ALTER TABLE SET NOT NULL subcommands to be executed ahead of
the ADD PRIMARY KEY operation in every case where it can't force the
column to be created already-not-null. This requires only minor surgery
in parse_utilcmd.c, and it makes for a much more satisfying spec for
transformIndexConstraint(): it's no longer having to take it on faith
that someone else will handle addition of NOT NULL constraints.
To make that work, we have to move the execution of AT_SetNotNull into
an ALTER pass that executes ahead of AT_PASS_ADD_INDEX. I moved it to
AT_PASS_COL_ATTRS, and put that after AT_PASS_ADD_COL to avoid failure
when the column is being added in the same command. This incidentally
fixes a bug in the only previous usage of AT_PASS_COL_ATTRS, for
AT_SetIdentity: it didn't work either for a newly-added column.
Playing around with this exposed a separate bug in ALTER TABLE ONLY ...
ADD PRIMARY KEY for partitioned tables. The intent of the ONLY modifier
in that context is to prevent doing anything that would require holding
lock for a long time --- but the implied SET NOT NULL would recurse to
the child partitions, and do an expensive validation scan for any child
where the column(s) were not already NOT NULL. To fix that, invent a
new ALTER subcommand AT_CheckNotNull that just insists that a child
column be already NOT NULL, and apply that, not AT_SetNotNull, when
recursing to children in this scenario. This results in a slightly laxer
definition of ALTER TABLE ONLY ... SET NOT NULL for partitioned tables,
too: that command will now work as long as all children are already NOT
NULL, whereas before it just threw up its hands if there were any
partitions.
In passing, clean up the API of generateClonedIndexStmt(): remove a
useless argument, ensure that the output argument is not left undefined,
update the header comment.
A small side effect of this change is that no-such-column errors in ALTER
TABLE ADD PRIMARY KEY now produce a different message that includes the
table name, because they are now detected by the SET NOT NULL step which
has historically worded its error that way. That seems fine to me, so
I didn't make any effort to avoid the wording change.
The basic bug #15580 is of very long standing, and these other bugs
aren't new in v12 either. However, this is a pretty significant change
in the way ALTER TABLE ADD PRIMARY KEY works. On balance it seems best
not to back-patch, at least not till we get some more confidence that
this patch has no new bugs.
Patch by me, but thanks to Jie Zhang for a preliminary version.
Discussion: https://postgr.es/m/15580-d1a6de5a3d65da51@postgresql.org
Discussion: https://postgr.es/m/1396E95157071C4EBBA51892C5368521017F2E6E63@G08CNEXMBPEKD02.g08.fujitsu.local M src/backend/catalog/index.c
M src/backend/commands/tablecmds.c
M src/backend/parser/parse_utilcmd.c
M src/include/nodes/parsenodes.h
M src/include/parser/parse_utilcmd.h
M src/test/modules/test_ddl_deparse/expected/alter_table.out
M src/test/modules/test_ddl_deparse/expected/create_table.out
M src/test/modules/test_ddl_deparse/test_ddl_deparse.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/identity.out
M src/test/regress/expected/indexing.out
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/identity.sql
M src/test/regress/sql/indexing.sql
Don’t request pretty-printed output from xmlNodeDump().
commit : c06e3550dc4163c3ff29a87283b605f0beb50bed
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Apr 2019 10:51:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Apr 2019 10:51:07 -0400 xml.c passed format = 1 to xmlNodeDump(), resulting in sometimes getting
extra whitespace (newlines + spaces) in the output. We don't really want
that, first because whitespace might be semantically significant in some
XML uses, and second because it happens only very inconsistently. Only
one case in our regression tests is affected.
This potentially affects the results of xpath() and the XMLTABLE construct,
when emitting nodeset values.
Note that the older code in contrib/xml2 doesn't do this; it seems
to have been an aboriginal bad decision in commit ea3b212fe.
While this definitely seems like a bug to me, the small number of
complaints to date argues against back-patching a behavioral change.
Hence, fix in HEAD only, at least for now.
Per report from Jean-Marc Voillequin.
Discussion: https://postgr.es/m/1EC8157EB499BF459A516ADCF135ADCE3A23A9CA@LON-WGMSX712.ad.moodys.net M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_2.out
Fix detection of passwords hashed with MD5 or SCRAM-SHA-256
commit : ccae190b916f27fbe4079ee4664d34cd1be47b79
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 23 Apr 2019 15:43:21 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 23 Apr 2019 15:43:21 +0900 This commit fixes a couple of issues related to the way password
verifiers hashed with MD5 or SCRAM-SHA-256 are detected, leading to
being able to store in catalogs passwords which do not follow the
supported hash formats:
- A MD5-hashed entry was checked based on if its header uses "md5" and
if the string length matches what is expected. Unfortunately the code
never checked if the hash only used hexadecimal characters, as reported
by Tom Lane.
- A SCRAM-hashed entry was checked based on only its header, which
should be "SCRAM-SHA-256$", but it never checked for any fields
afterwards, as reported by Jonathan Katz.
Backpatch down to v10, which is where SCRAM has been introduced, and
where password verifiers in plain format have been removed.
Author: Jonathan Katz
Reviewed-by: Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/016deb6b-1f0a-8e9f-1833-a8675b170aa9@postgresql.org
Backpatch-through: 10 M src/backend/libpq/auth-scram.c
M src/backend/libpq/crypt.c
M src/include/common/md5.h
M src/include/libpq/scram.h
M src/test/regress/expected/password.out
M src/test/regress/sql/password.sql
Convert gist to compute page level xid horizon on primary.
commit : b5f58cf213bdab7e726f7b09c1137b4ea397fc0b
author : Andres Freund <andres@anarazel.de>
date : Mon, 22 Apr 2019 14:28:30 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 22 Apr 2019 14:28:30 -0700 Due to parallel development, gist added the missing conflict
information in c952eae52a3, while 558a9165e08 moved that computation
to the primary for the index types that already had it. Thus adapt
gist to also compute on the primary, using
index_compute_xid_horizon_for_tuples() instead of its own copy of the
logic.
This also adds pg_waldump support for XLOG_GIST_DELETE records, which
previously was not properly present.
Bumps WAL version.
Author: Andres Freund
Discussion: https://postgr.es/m/20190406050243.bszosdg4buvabfrt@alap3.anarazel.de M src/backend/access/gist/gist.c
M src/backend/access/gist/gistxlog.c
M src/backend/access/rmgrdesc/gistdesc.c
M src/include/access/gist_private.h
M src/include/access/gistxlog.h
M src/include/access/xlog_internal.h
Fix documentation of pg_start_backup and pg_stop_backup functions.
commit : b804c1837b55722369d30be707738c098a75cd7a
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 23 Apr 2019 02:41:58 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 23 Apr 2019 02:41:58 +0900 This commit adds the description that "non-exclusive" pg_start_backup
and pg_stop_backup can be executed even during recovery. Previously
it was wrongly documented that those functions are not allowed to be
executed during recovery.
Back-patch to 9.6 where non-exclusive backup API was added.
Discussion: https://postgr.es/m/CAHGQGwEuAYrEX7Yhmf2MCrTK81HDkkg-JqsOUh8zw6+zYC5zzw@mail.gmail.com M doc/src/sgml/func.sgml
Fix mvdistinct and dependencies size calculations
commit : d08c44f7a4ec574110bf1587fe8bd682b8557e0f
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 21 Apr 2019 19:54:15 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 21 Apr 2019 19:54:15 +0200 The formulas used to calculate size while (de)serializing mvndistinct
and functional dependencies were based on offset() of the structs. But
that is incorrect, because the structures are not copied directly, we
we copy the individual fields directly.
At the moment this works fine, because there is no alignment padding
on any platform we support. But it might break if we ever added some
fields into any of the structs, for example. It's also confusing.
Fixed by reworking the macros to directly sum sizes of serialized
fields. The macros are now useful only for serialiation, so there is
no point in keeping them in the public header file. So make them
private by moving them to the .c files.
Also adds a couple more asserts to check the serialization, and fixes
an incorrect allocation of MVDependency instead of (MVDependency *).
Reported-By: Tom Lane
Discussion: https://postgr.es/m/29785.1555365602@sss.pgh.pa.us M src/backend/statistics/dependencies.c
M src/backend/statistics/mvdistinct.c
M src/include/statistics/statistics.h
docs: reorder collation regression test order in paragraph
commit : bfbc150e39515c08a5691c7da4291d1b9f2b2b9c
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 20 Apr 2019 11:18:43 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 20 Apr 2019 11:18:43 -0400 Backpatch-through: 10 M doc/src/sgml/regress.sgml
GSSAPI: Improve documentation and tests
commit : eb882a1b717589777e068dc6671830226f3aa7f0
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 19 Apr 2019 21:22:22 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 19 Apr 2019 21:22:22 -0400 The GSSAPI encryption patch neglected to update the protocol
documentation to describe how to set up a GSSAPI encrypted connection
from a client to the server, so fix that by adding the appropriate
documentation to protocol.sgml.
The tests added for encryption support were overly long and couldn't be
run in parallel due to race conditions; this was largely because each
test was setting up its own KDC to perform the tests. Instead, merge
the authentication tests and the encryption tests into the original
test, where we only create one KDC to run the tests with. Also, have
the tests check what the server's opinion is of the connection and if it
was GSS authenticated or encrypted using the pg_stat_gssapi view.
In passing, fix the libpq label for GSSENC-Mode to be consistent with
the "PGGSSENCMODE" environment variable.
Missing protocol documentation pointed out by Michael Paquier.
Issues with the tests pointed out by Tom Lane and Peter Eisentraut.
Refactored tests and added documentation by me.
Reviewed by Robbie Harwood (protocol documentation) and Michael Paquier
(rework of the tests). M doc/src/sgml/protocol.sgml
M src/interfaces/libpq/fe-connect.c
M src/test/kerberos/t/001_auth.pl
D src/test/kerberos/t/002_enc.pl
Fix slot type issue for fuzzy distance index scan over out-of-core table AM.
commit : b8b94ea129ffc988c2d30eb2b5aa65a93329b8fa
author : Andres Freund <andres@anarazel.de>
date : Fri, 19 Apr 2019 11:25:48 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 19 Apr 2019 11:25:48 -0700 For amcanreorderby scans the nodeIndexscan.c's reorder queue holds
heap tuples, but the underlying table likely does not. Before this fix
we'd return different types of slots, depending on whether the tuple
came from the reorder queue, or from the index + table.
While that could be fixed by signalling that the node doesn't return a
fixed type of slot, it seems better to instead remove the separate
slot for the reorder queue, and use ExecForceStoreHeapTuple() to store
tuples from the queue. It's not particularly common to need
reordering, after all.
This reverts most of the iss_ReorderQueueSlot related changes to
nodeIndexscan.c made in 1a0586de3657cd3, except that now
ExecForceStoreHeapTuple() is used instead of ExecStoreHeapTuple().
Noticed when testing zheap against the in-core version of tableam.
Author: Andres Freund M src/backend/executor/nodeIndexscan.c
M src/include/nodes/execnodes.h
Fix two memory leaks around force-storing tuples in slots.
commit : 88e6ad3054ddd5aa0dee12e5def2c335fe92a414
author : Andres Freund <andres@anarazel.de>
date : Fri, 19 Apr 2019 11:33:37 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 19 Apr 2019 11:33:37 -0700 As reported by Tom, when ExecStoreMinimalTuple() had to perform a
conversion to store the minimal tuple in the slot, it forgot to
respect the shouldFree flag, and leaked the tuple into the current
memory context if true. Fix that by freeing the tuple in that case.
Looking at the relevant code made me (Andres) realize that not having
the shouldFree parameter to ExecForceStoreHeapTuple() was a bad
idea. Some callers had to locally implement the necessary logic, and
in one case it was missing, creating a potential per-group leak in
non-hashed aggregation.
The choice to not free the tuple in ExecComputeStoredGenerated() is
not pretty, but not introduced by this commit - I'll start a separate
discussion about it.
Reported-By: Tom Lane
Discussion: https://postgr.es/m/366.1555382816@sss.pgh.pa.us M contrib/postgres_fdw/postgres_fdw.c
M src/backend/commands/trigger.c
M src/backend/executor/execTuples.c
M src/backend/executor/nodeAgg.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/executor/nodeModifyTable.c
M src/include/executor/tuptable.h
Fix problems with auto-held portals.
commit : 4d5840cea96d7f893389664dd423716b38fded7a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 Apr 2019 11:20:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 Apr 2019 11:20:37 -0400 HoldPinnedPortals() did things in the wrong order: it must not mark
a portal autoHeld until it's been successfully held. Otherwise,
a failure while persisting the portal results in a server crash
because we think the portal is in a good state when it's not.
Also add a check that portal->status is READY before attempting to
hold a pinned portal. We have such a check before the only other
use of HoldPortal(), so it seems unwise not to check it here.
Lastly, rethink the responsibility for where to call HoldPinnedPortals.
The comment for it imagined that it was optional for any individual PL
to call it or not, but that cannot be the case: if some outer level of
procedure has a pinned portal, failing to persist it when an inner
procedure commits is going to be trouble. Let's have SPI do it instead
of the individual PLs. That's not a complete solution, since in theory
a PL might not be using SPI to perform commit/rollback, but such a PL
is going to have to be aware of lots of related requirements anyway.
(This change doesn't cause an API break for any external PLs that might
be calling HoldPinnedPortals per the old regime, because calling it
twice during a commit or rollback sequence won't hurt.)
Per bug #15703 from Julian Schauder. Back-patch to v11 where this code
came in.
Discussion: https://postgr.es/m/15703-c12c5bc0ea34ba26@postgresql.org M src/backend/executor/spi.c
M src/backend/utils/mmgr/portalmem.c
M src/pl/plperl/plperl.c
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql
M src/pl/plpython/plpy_plpymodule.c
Fix collection of typos and grammar mistakes in docs and comments
commit : 148266fa354a47543f6c0325cd1ea900ead4aac6
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 19 Apr 2019 16:57:40 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 19 Apr 2019 16:57:40 +0900 Author: Justin Pryzby
Discussion: https://postgr.es/m/20190330224333.GQ5815@telsasoft.com M doc/src/sgml/ecpg.sgml
M doc/src/sgml/ref/create_index.sgml
M src/backend/jit/llvm/llvmjit_inline.cpp
M src/backend/optimizer/plan/planner.c
M src/backend/utils/hash/dynahash.c
M src/interfaces/libpq/fe-auth.c
Clean up some documentation for log_statement_sample_rate
commit : bc540f98599b875e7ee67086291cdb96997db3fc
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 19 Apr 2019 16:26:41 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 19 Apr 2019 16:26:41 +0900 This was missing from 88bdbd3.
Author: Christoph Berg, Justin Pryzby
Discussion: https://postgr.es/m/20190403215938.GA26375@alvherre.pgsql
Discussion: https://postgr.es/m/20190330224333.GQ5815@telsasoft.com M doc/src/sgml/config.sgml
Remove dependency to pageinspect in recovery tests
commit : 5a9323eab6e2c47e4caee9ab4b5117ba01368253
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 19 Apr 2019 15:51:23 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 19 Apr 2019 15:51:23 +0900 If contrib/pageinspect is not installed, this causes the test checking
the minimum recovery point to fail. The point is that the dependency
with pageinspect is not really necessary as the test does also all
checks with an offline cluster by scanning directly the on-disk pages,
which is enough for the purpose of the test.
Per complaint from Tom Lane.
Author: Michael Paquier
Discussion: https://postgr.es/m/17806.1555566345@sss.pgh.pa.us M src/test/recovery/Makefile
M src/test/recovery/t/016_min_consistency.pl
Fix potential use-after-free for BEFORE UPDATE row triggers on non-core AMs.
commit : 75e03eabeaac8fd229b14f74de55d0e1470903c4
author : Andres Freund <andres@anarazel.de>
date : Thu, 18 Apr 2019 17:53:54 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 18 Apr 2019 17:53:54 -0700 When such a trigger returns the old row version, it naturally get
stored in the slot for the trigger result. When a table AMs doesn't
store HeapTuples internally, ExecBRUpdateTriggers() frees the old row
version passed to triggers - but before this fix it might still be
referenced by the slot holding the new tuple.
Noticed when running the out-of-core zheap AM against the in-core
version of tableam.
Author: Andres Freund M src/backend/commands/trigger.c
Fix handling of temp and unlogged tables in FOR ALL TABLES publications
commit : bb385c4fb0f4eb33d2bc7e484061565ba51cc790
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 16 Apr 2019 10:37:44 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 16 Apr 2019 10:37:44 +0200 If a FOR ALL TABLES publication exists, temporary and unlogged tables
are ignored for publishing changes. But CheckCmdReplicaIdentity()
would still check in that case that such a table has a replica
identity set before accepting updates. To fix, have
GetRelationPublicationActions() return that such a table publishes no
actions.
Discussion: https://www.postgresql.org/message-id/f3f151f7-c4dd-1646-b998-f60bd6217dd3@2ndquadrant.com M src/backend/utils/cache/relcache.c
M src/test/subscription/t/100_bugs.pl
docs: correct typo-ed path to heapam_handler.c.
commit : 1cebfdee0087624af2fc99a000642c2db4dfbfc9
author : Andres Freund <andres@anarazel.de>
date : Wed, 17 Apr 2019 17:31:54 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 17 Apr 2019 17:31:54 -0700 Reported-By: Michael Paquier, Michel Pelletier
Discussion:
https://postgr.es/m/20190410025531.GA2728@paquier.xyz
https://postgr.es/m/CACxu=v+u_QTeFqdajCHv3i4QmzV_63arVb57R19dSKtThdSLkQ@mail.gmail.com M doc/src/sgml/tableam.sgml
pg_dump: Remove stray option parsing support for -o.
commit : 4d0183592764629d38182e30642b1aef8baeb987
author : Andres Freund <andres@anarazel.de>
date : Wed, 17 Apr 2019 17:28:02 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 17 Apr 2019 17:28:02 -0700 I (Andres) missed this in 578b229718e8f, the removal of WITH OIDS
support.
Author: Daniel Verite
Discussion: https://postgr.es/m/f06e9735-3717-4904-8c95-47d0b9c3bb10@manitou-mail.org M src/bin/pg_dump/pg_dump.c
docs: cleanup/remove/update references to OID column.
commit : f6b39171f3d65155b9390c2c69bc5b3469f923a8
author : Andres Freund <andres@anarazel.de>
date : Wed, 17 Apr 2019 17:22:56 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 17 Apr 2019 17:22:56 -0700 I (Andres) missed these in 578b229718e8f.
Author: Justin Pryzby, editorialized a bit by Andres Freund
Reviewed-By: Daniel Verite, Andres Freund
Discussion: https://postgr.es/m/20190408002847.GA904@telsasoft.com M doc/src/sgml/catalogs.sgml
M doc/src/sgml/ddl.sgml
M doc/src/sgml/information_schema.sgml
M doc/src/sgml/ref/create_trigger.sgml
M doc/src/sgml/ref/insert.sgml
M doc/src/sgml/ref/psql-ref.sgml
M doc/src/sgml/spi.sgml
Tie loose ends in psql’s new \dP command
commit : 421a2c48328c88eb31f6b29979218f0a350bb739
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 17 Apr 2019 18:35:41 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 17 Apr 2019 18:35:41 -0400 * Remove one unnecessary pg_class join in SQL command. Not needed,
because we use a regclass cast instead.
* Doc: refer to "partitioned relations" rather than specifically tables,
since indexes are also displayed.
* Rename "On table" column to "Table", for consistency with \di.
Author: Justin Pryzby
Discussion: https://postgr.es/m/20190407212525.GB10080@telsasoft.com M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/describe.c
M src/test/regress/expected/psql.out
psql: display tablespace for partitioned indexes
commit : b036982db786f7ef6c118419e7e832167ad4a6a7
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 17 Apr 2019 18:17:43 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 17 Apr 2019 18:17:43 -0400 Nothing was shown previously. M src/bin/psql/describe.c
M src/test/regress/input/tablespace.source
M src/test/regress/output/tablespace.source
postgresql.conf.sample: add proper defaults for include actions
commit : fb9c475597c245562a28d1e916b575ac4ec5c19f
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 17 Apr 2019 18:12:10 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 17 Apr 2019 18:12:10 -0400 Previously, include actions include_dir, include_if_exists, and include
listed commented-out values which were not the defaults, which is
inconsistent with other entries. Instead, replace them with '', which
is the default value.
Reported-by: Emanuel Araújo
Discussion: https://postgr.es/m/CAMuTAkYMx6Q27wpELDR3_v9aG443y7ZjeXu15_+1nGUjhMWOJA@mail.gmail.com
Backpatch-through: 9.4 M src/backend/utils/misc/postgresql.conf.sample
docs: clarify pg_upgrade’s recovery behavior
commit : 64bbe1039962a75cb292fb557e2e79a58c77ec33
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 17 Apr 2019 18:01:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 17 Apr 2019 18:01:02 -0400 The previous paragraph trying to explain --check, --link, and no --link
modes and the various points of failure was too complex. Instead, use
bullet lists and sublists.
Reported-by: Daniel Gustafsson
Discussion: https://postgr.es/m/qtqiv7hI87s_Xvz5ZXHCaH-1-_AZGpIDJowzlRjF3-AbCr3RhSNydM_JCuJ8DE4WZozrtxhIWmyYTbv0syKyfGB6cYMQitp9yN-NZMm-oAo=@yesql.se
Backpatch-through: 9.4 M doc/src/sgml/ref/pgupgrade.sgml
Fix unportable code in pgbench.
commit : 1a75c1d0c5d967ea2adcd7129092687cded4e7bf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Apr 2019 17:30:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Apr 2019 17:30:29 -0400 The buildfarm points out that UINT64_FORMAT might not work with sscanf;
it's calibrated for our printf implementation, which might not agree
with the platform-supplied sscanf. Fall back to just accepting an
unsigned long, which is already more than the documentation promises.
Oversight in e6c3ba7fb; back-patch to v11, as that was. M src/bin/pgbench/pgbench.c
Fix assorted minor bogosity in GSSAPI transport error messages.
commit : 8cde7f49483d7e21569f61108fc80a8fe9e83e56
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Apr 2019 17:06:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Apr 2019 17:06:50 -0400 I noted that some buildfarm members were complaining about %ld being
used to format values that are (probably) declared size_t. Use %zu
instead, and insert a cast just in case some versions of the GSSAPI
API declare the length field differently. While at it, clean up
gratuitous differences in wording of equivalent messages, show
the complained-of length in all relevant messages not just some,
include trailing newline where needed, adjust random deviations
from project-standard code layout and message style, etc. M src/backend/libpq/be-secure-gssapi.c
M src/interfaces/libpq/fe-secure-gssapi.c
Minor jsonpath fixes.
commit : b4f96d69ad197731c1f5b959e1234c9ba3517ecb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Apr 2019 13:37:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Apr 2019 13:37:00 -0400 Restore missed "make clean" rule, fix misspelling.
John Naylor
Discussion: https://postgr.es/m/CACPNZCt5B8jDCCGQiFoSuqmg-za_NCy4QDioBTLaNRih9+-bXg@mail.gmail.com M src/backend/utils/adt/Makefile
M src/backend/utils/adt/jsonpath_scan.l
Return NULL for checksum failures if checksums are not enabled
commit : 252b707bc41cc9bf6c55c18d8cb302a6176b7e48
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 17 Apr 2019 13:51:48 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 17 Apr 2019 13:51:48 +0200 Returning 0 could falsely indicate that there is no problem. NULL
correctly indicates that there is no information about potential
problems.
Also return 0 as numbackends instead of NULL for shared objects (as no
connection can be made to a shared object only).
Author: Julien Rouhaud <rjuju123@gmail.com>
Reviewed-by: Robert Treat <rob@xzilla.net> M doc/src/sgml/monitoring.sgml
M src/backend/catalog/system_views.sql
M src/backend/utils/adt/pgstatfuncs.c
M src/test/regress/expected/rules.out
Fix thinko introduced by 82a5649 in slot.c
commit : 9010156445c420361c2cef9557751c0b8b52644b
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 17 Apr 2019 10:01:22 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 17 Apr 2019 10:01:22 +0900 When saving a replication slot, failing to close the temporary path used
to save the slot information is considered as a failure and reported as
such. However the code forgot to leave immediately as other failure
paths do.
Noticed while looking up at this area of the code for another patch. M src/backend/replication/slot.c
Simplify some ERROR paths clearing wait events and transient files
commit : 47ac2033d460cefbbda2e39732e18de521dc6a36
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 17 Apr 2019 09:51:45 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 17 Apr 2019 09:51:45 +0900 Transient files and wait events get normally cleaned up when seeing an
exception (be it in the context of a transaction for a backend or
another process like the checkpointer), hence there is little point in
complicating error code paths to do this work. This shaves a bit of
code, and removes some extra handling with errno which needed to be
preserved during the cleanup steps done.
Reported-by: Masahiko Sawada
Author: Michael Paquier
Reviewed-by: Tom Lane, Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoDhHYVq5KkXfkaHhmjA-zJYj-e4teiRAJefvXuKJz1tKQ@mail.gmail.com M src/backend/access/transam/twophase.c
M src/backend/replication/logical/origin.c
M src/backend/replication/slot.c
M src/backend/storage/file/copydir.c
Rework handling of invalid indexes with REINDEX CONCURRENTLY
commit : a6dcf9df4d91ff0db23579f9114079abe6f3e2bf
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 17 Apr 2019 09:33:51 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 17 Apr 2019 09:33:51 +0900 Per discussion with others, allowing REINDEX INDEX CONCURRENTLY to work
for invalid indexes when working directly on them can have a lot of
value to unlock situations with invalid indexes without having to use a
dance involving DROP INDEX followed by an extra CREATE INDEX
CONCURRENTLY (which would not work for indexes with constraint
dependency anyway). This also does not create extra bloat on the
relation involved as this works on individual indexes, so let's enable
it.
Note that REINDEX TABLE CONCURRENTLY still bypasses invalid indexes as
we don't want to bloat the number of indexes defined on a relation in
the event of multiple and successive failures of REINDEX CONCURRENTLY.
More regression tests are added to cover those behaviors, using an
invalid index created with CREATE INDEX CONCURRENTLY.
Reported-by: Dagfinn Ilmari Mannsåker, Álvaro Herrera
Author: Michael Paquier
Reviewed-by: Peter Eisentraut, Dagfinn Ilmari Mannsåker
Discussion: https://postgr.es/m/20190411134947.GA22043@alvherre.pgsql M doc/src/sgml/ref/create_index.sgml
M doc/src/sgml/ref/reindex.sgml
M src/backend/commands/indexcmds.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Add index terms for reloptions in documentation.
commit : c8e0f6bbdb5ff0f235246af5b567b21dcfc1d22a
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 16 Apr 2019 23:16:20 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 16 Apr 2019 23:16:20 +0900 Author: Fujii Masao
Reviewed-By: Alvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/CAHGQGwHyKt9-xkibVguPzYqKgb_2tdw14Ub1XDTu08kyHMiTQA@mail.gmail.com M doc/src/sgml/config.sgml
M doc/src/sgml/ref/create_index.sgml
M doc/src/sgml/ref/create_table.sgml
Better scaling of images in HTML output
commit : e446cde16d676b528f3aa91dcbe5bb9c5a3776d8
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 16 Apr 2019 14:27:56 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 16 Apr 2019 14:27:56 +0200 Turn on the previously disabled automatic scaling of images in HTML
output. To avoid images looking too large on nowadays-normal screens,
restrict the width to 75% on such screens.
Some work is still necessary because SVG images without a viewBox
still won't scale, but that will a separate patch.
Discussion: https://www.postgresql.org/message-id/flat/6d2442d1-84a2-36ef-e014-b6d1ece8a139%40postgresql.org M doc/src/sgml/stylesheet-html-common.xsl
M doc/src/sgml/stylesheet.css
Remove duplicate assignment when initializing logical decoder context
commit : 5ed4b123b6a678bc6243047846870f7f46e9c67b
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 16 Apr 2019 15:08:38 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 16 Apr 2019 15:08:38 +0900 The private data in the WAL reader is already getting set when
allocating it.
Author: Antonin Houska
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/30563.1555329094@localhost M src/backend/replication/logical/logical.c
Don’t write to stdin of a test process that could have already exited.
commit : e12a4726127b90b8fc5e75690fe4527f1866412d
author : Noah Misch <noah@leadboat.com>
date : Mon, 15 Apr 2019 18:13:44 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 15 Apr 2019 18:13:44 -0700 Instead, close that stdin. Per buildfarm member conchuela. Back-patch
to 9.6, where the test was introduced.
Discussion: https://postgr.es/m/26478.1555373328@sss.pgh.pa.us M src/test/recovery/t/017_shm.pl
Use [FLEXIBLE_ARRAY_MEMBER] not [1] in MultiSortSupportData.
commit : dde7fb7836c7428f79cb3cd88ca5febb802e767e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Apr 2019 19:32:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Apr 2019 19:32:36 -0400 This struct seems to have not gotten the word about preferred
coding style for variable-length arrays. M src/include/statistics/extended_stats_internal.h
Convert pre-existing stats_ext tests to new style
commit : dbb984128ebf6b4bd6f12b4579ee9103ef1ca749
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 16 Apr 2019 00:02:22 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 16 Apr 2019 00:02:22 +0200 The regression tests added in commit 7300a69950 test cardinality
estimates using a function that extracts the interesting pieces
from the EXPLAIN output, instead of testing the whole plan. That
seems both easier to understand and less fragile, so this applies
the same approach to pre-existing tests of ndistinct coefficients
and functional dependencies.
Discussion: https://postgr.es/m/dfdac334-9cf2-2597-fb27-f0fb3753f435@2ndquadrant.com M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Fix pg_mcv_list deserialization
commit : 3824ca30d162611fdaade403d3aec449fecd0924
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 16 Apr 2019 00:01:39 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 16 Apr 2019 00:01:39 +0200 The memcpy() was copying type OIDs in the wrong direction, so the
deserialized MCV list always had them as 0. This is mostly harmless
except when printing the data in pg_mcv_list_items(), in which case
it reported
ERROR: cache lookup failed for type 0
Also added a simple regression test for pg_mcv_list_items() function,
printing a single-item MCV list.
Reported-By: Dean Rasheed
Discussion: https://postgr.es/m/CAEZATCX6T0iDTTZrqyec4Cd6b4yuL7euu4=rQRXaVBAVrUi1Cg@mail.gmail.com M src/backend/statistics/mcv.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Fix failure with textual partition hash keys.
commit : 4b40e44f07c727c7a82b291d3b60098dd99f3f64
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Apr 2019 16:47:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Apr 2019 16:47:09 -0400 Commit 5e1963fb7 overlooked two places in partbounds.c that now
need to pass a collation identifier to the hash functions for
a partition key column.
Amit Langote, per report from Jesper Pedersen
Discussion: https://postgr.es/m/a620f85a-42ab-e0f3-3337-b04b97e2e2f5@redhat.com M src/backend/partitioning/partbounds.c
M src/test/regress/expected/hash_part.out
M src/test/regress/sql/hash_part.sql
Avoid possible regression test instability in timestamp.sql.
commit : 47169c25500a70a7d04076860717f2f4f0ea83a7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Apr 2019 16:19:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 15 Apr 2019 16:19:51 -0400 Concurrent autovacuum could result in a change in the order of the
live rows in timestamp_tbl. While this would not happen with the
default autovacuum parameters, it's fairly easy to hit if
autovacuum_vacuum_threshold is made small enough to allow autovac
to decide to process this table. That's a stumbling block for trying
to exercise autovacuum aggressively using the core regression tests.
To fix, replace an unqualified DELETE with a TRUNCATE. There's a
similar DELETE just above (and no order-sensitive queries between),
so this doesn't lose any test coverage and might indeed be argued
to improve it.
Discussion: https://postgr.es/m/17428.1555348950@sss.pgh.pa.us M src/test/regress/expected/timestamp.out
M src/test/regress/sql/timestamp.sql
Fix division by zero in _bt_vacuum_needs_cleanup()
commit : 1e871981823a68ec9e0174b652e8d27e05ce08bb
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 15 Apr 2019 20:20:43 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 15 Apr 2019 20:20:43 +0300 Checks inside _bt_vacuum_needs_cleanup() allow division by zero to happen when
metad->btm_last_cleanup_num_heap_tuples == 0. This commit adjusts the
expression so that no division by zero might happen.
Reported-by: Piotr Stefaniak
Discussion: https://postgr.es/m/DB8PR03MB5931C41F7787A95313F08322F22A0%40DB8PR03MB5931.eurprd03.prod.outlook.com
Reviewed-by: Masahiko Sawada
Backpatch-through: 11 M src/backend/access/nbtree/nbtree.c
Fix thinko in ExecCleanupTupleRouting().
commit : 3a45321a491711b556d2cf8f6904ab989b9d0b08
author : Etsuro Fujita <efujita@postgresql.org>
date : Mon, 15 Apr 2019 19:01:09 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Mon, 15 Apr 2019 19:01:09 +0900 Commit 3f2393edef changed ExecCleanupTupleRouting() so that it skipped
cleaning up subplan resultrels before calling EndForeignInsert(), but
that would cause an issue: when those resultrels were foreign tables,
the FDWs would fail to shut down. Repair by skipping it after calling
EndForeignInsert() as before.
Author: Etsuro Fujita
Reviewed-by: David Rowley and Amit Langote
Discussion: https://postgr.es/m/5CAF3B8F.2090905@lab.ntt.co.jp M src/backend/executor/execPartition.c
Unbreak index optimization for LIKE on bytea
commit : abb9c63b2c00109183cdb9f588d2f23fc383ed38
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 15 Apr 2019 09:26:23 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 15 Apr 2019 09:26:23 +0200 The same code is used to handle both text and bytea, but bytea is not
collation-aware, so we shouldn't call get_collation_isdeterministic()
in that case, since that will error out with an invalid collation.
Reported-by: Jeevan Chalke <jeevan.chalke@enterprisedb.com>
Discussion: https://www.postgresql.org/message-id/flat/CAM2%2B6%3DWaf3qJ1%3DyVTUH8_yG-SC0xcBMY%2BSFLhvKKNnWNXSUDBw%40mail.gmail.com M src/backend/utils/adt/like_support.c
M src/test/regress/expected/strings.out
M src/test/regress/sql/strings.sql
Fix SHOW ALL command for non-superusers with replication connection
commit : c34677fdaa73f089d557554a9cd479b9bd5b5143
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 15 Apr 2019 12:34:32 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 15 Apr 2019 12:34:32 +0900 Since Postgres 10, SHOW commands can be triggered with replication
connections in a WAL sender context, however it missed that a
transaction context is needed for syscache lookups. This commit makes
sure that the syscache lookups can happen correctly by setting a
transaction context when running SHOW commands in a WAL sender.
Superuser-only parameters can be displayed using SHOW commands not only
to superusers, but also to members of system role pg_read_all_settings,
which requires a syscache lookup to check if the connected role is a
member of this system role or not, or the instance crashes. Superusers
do not need to check the syscache so it worked correctly in this case.
New tests are added to cover this issue.
Reported-by: Alexander Kukushkin
Author: Michael Paquier
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/15734-2daa8761eeed8e20@postgresql.org
Backpatch-through: 10 M src/backend/replication/walsender.c
M src/test/recovery/t/001_stream_rep.pl
Test both 0.0.0.0 and 127.0.0.x addresses to find a usable port.
commit : 4ab02e8156270592c1eae03d5b9ee36bb8c761c2
author : Noah Misch <noah@leadboat.com>
date : Sun, 14 Apr 2019 20:02:19 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 14 Apr 2019 20:02:19 -0700 Commit c098509927f9a49ebceb301a2cb6a477ecd4ac3c changed
PostgresNode::get_new_node() to probe 0.0.0.0 instead of 127.0.0.1, but
the new test was less effective for Windows native Perl. This increased
the failure rate of buildfarm members bowerbird and jacana. Instead,
test 0.0.0.0 and concrete addresses. This restores the old level of
defense, but the algorithm is still subject to its longstanding time of
check to time of use race condition. Back-patch to 9.6, like the
previous change.
Discussion: https://postgr.es/m/GrdLgAdUK9FdyZg8VIcTDKVOkys122ZINEb3CjjoySfGj2KyPiMKTh1zqtRp0TAD7FJ27G-OBB3eplxIB5GhcQH5o8zzGZfp0MuJaXJxVxk=@yesql.se M src/test/perl/PostgresNode.pm
Switch TAP tests of pg_rewind to use non-superuser role, take two
commit : d9f543e9e9be15f92abdeaf870e57ef289020191
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 14 Apr 2019 18:47:51 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 14 Apr 2019 18:47:51 +0900 Up to now the tests of pg_rewind have been using a superuser for all its
tests (which is the default of many tests actually, and something that
ought to be reviewed) when involving an online source server, still it
is possible to use a non-superuser role to do that as long as this role
is granted permissions to execute all the source-side functions used for
the rewind. This is possible since v11, and was already documented as
of bfc8068.
PostgresNode::init is extended so as callers of this routine can add
extra options to configure the authentication of a new node, which gets
used by this commit, and allows the tests to work properly on Windows
where SSPI is used.
This will allow to catch up easily any change in pg_rewind if the tool
begins to use more backend-side functions, so as the properties
introduced by v11 are kept.
Per suggestion from Peter Eisentraut.
Author: Michael Paquier
Reviewed-by: Magnus Hagander
Discussion: https://postgr.es/m/20190411041336.GM2728@paquier.xyz M src/bin/pg_rewind/t/RewindTest.pm
M src/test/perl/PostgresNode.pm
MSYS: Translate REGRESS_SHLIB to a Windows file name.
commit : 9daefff1226087602d25837b6b30154b3a916ea8
author : Noah Misch <noah@leadboat.com>
date : Sun, 14 Apr 2019 00:42:34 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 14 Apr 2019 00:42:34 -0700 Per buildfarm member jacana. Back-patch to v11; earlier branches skip
the affected test under msys.
Discussion: https://postgr.es/m/GrdLgAdUK9FdyZg8VIcTDKVOkys122ZINEb3CjjoySfGj2KyPiMKTh1zqtRp0TAD7FJ27G-OBB3eplxIB5GhcQH5o8zzGZfp0MuJaXJxVxk=@yesql.se M src/test/recovery/t/017_shm.pl
When Perl “kill(9, …)” fails, try “pg_ctl kill”.
commit : 947a35014fdc2ec74cbf06c7dbac6eea6fae90c6
author : Noah Misch <noah@leadboat.com>
date : Sat, 13 Apr 2019 11:09:27 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 13 Apr 2019 11:09:27 -0700 Per buildfarm member jacana, the former fails under msys Perl 5.8.8.
Back-patch to 9.6, like the code in question.
Discussion: https://postgr.es/m/GrdLgAdUK9FdyZg8VIcTDKVOkys122ZINEb3CjjoySfGj2KyPiMKTh1zqtRp0TAD7FJ27G-OBB3eplxIB5GhcQH5o8zzGZfp0MuJaXJxVxk=@yesql.se M src/test/perl/PostgresNode.pm
Prevent memory leaks associated with relcache rd_partcheck structures.
commit : 5f1433ac5e7f943b29ef01266b6b8fc915e6b917
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Apr 2019 13:22:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 13 Apr 2019 13:22:26 -0400 The original coding of generate_partition_qual() just copied the list
of predicate expressions into the global CacheMemoryContext, making it
effectively impossible to clean up when the owning relcache entry is
destroyed --- the relevant code in RelationDestroyRelation() only managed
to free the topmost List header :-(. This resulted in a session-lifespan
memory leak whenever a table partition's relcache entry is rebuilt.
Fortunately, that's not normally a large data structure, and rebuilds
shouldn't occur all that often in production situations; but this is
still a bug worth fixing back to v10 where the code was introduced.
To fix, put the cached expression tree into its own small memory context,
as we do with other complicated substructures of relcache entries.
Also, deal more honestly with the case that a partition has an empty
partcheck list; while that probably isn't a case that's very interesting
for production use, it's legal.
In passing, clarify comments about how partitioning-related relcache
data structures are managed, and add some Asserts that we're not leaking
old copies when we overwrite these data fields.
Amit Langote and Tom Lane
Discussion: https://postgr.es/m/7961.1552498252@sss.pgh.pa.us M src/backend/partitioning/partdesc.c
M src/backend/utils/cache/partcache.c
M src/backend/utils/cache/relcache.c
M src/include/utils/rel.h
Consistently test for in-use shared memory.
commit : c098509927f9a49ebceb301a2cb6a477ecd4ac3c
author : Noah Misch <noah@leadboat.com>
date : Fri, 12 Apr 2019 22:36:38 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 12 Apr 2019 22:36:38 -0700 postmaster startup scrutinizes any shared memory segment recorded in
postmaster.pid, exiting if that segment matches the current data
directory and has an attached process. When the postmaster.pid file was
missing, a starting postmaster used weaker checks. Change to use the
same checks in both scenarios. This increases the chance of a startup
failure, in lieu of data corruption, if the DBA does "kill -9 `head -n1
postmaster.pid` && rm postmaster.pid && pg_ctl -w start". A postmaster
will no longer stop if shmat() of an old segment fails with EACCES. A
postmaster will no longer recycle segments pertaining to other data
directories. That's good for production, but it's bad for integration
tests that crash a postmaster and immediately delete its data directory.
Such a test now leaks a segment indefinitely. No "make check-world"
test does that. win32_shmem.c already avoided all these problems. In
9.6 and later, enhance PostgresNode to facilitate testing. Back-patch
to 9.4 (all supported versions).
Reviewed (in earlier versions) by Daniel Gustafsson and Kyotaro HORIGUCHI.
Discussion: https://postgr.es/m/20190408064141.GA2016666@rfd.leadboat.com M src/Makefile.global.in
M src/backend/port/sysv_shmem.c
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/ipci.c
M src/backend/utils/init/postinit.c
M src/include/storage/ipc.h
M src/include/storage/pg_shmem.h
M src/test/perl/PostgresNode.pm
A src/test/recovery/t/017_shm.pl
M src/tools/msvc/vcregress.pl
Revert “Switch TAP tests of pg_rewind to use a role with minimal permissions”
commit : db8db624e826efbe16aab1ae921bae071f98f099
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 13 Apr 2019 13:20:21 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 13 Apr 2019 13:20:21 +0900 This reverts commit d4e2a84, which added a new user with limited
permissions to run the TAP tests of pg_rewind. Buildfarm machine
members on Windows jacana and bowerbird have been complaining about
that, the new role not being able to run the rewind because SSPI is not
configured to allow it.
Fixing the test requires passing down directly the new user to
pg_regress with --create-role so as SSPI can work properly.
Reported-by: Andrew Dunstan
Discussion: https://postgr.es/m/3cd43d33-f415-cc41-ade3-7230ab15b2c9@2ndQuadrant.com M src/bin/pg_rewind/t/RewindTest.pm
Show shared object statistics in pg_stat_database
commit : 77bd49adba4711b4497e7e39a5ec3a9812cbd52a
author : Magnus Hagander <magnus@hagander.net>
date : Fri, 12 Apr 2019 14:04:50 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Fri, 12 Apr 2019 14:04:50 +0200 This adds a row to the pg_stat_database view with datoid 0 and datname
NULL for those objects that are not in a database. This was added
particularly for checksums, but we were already tracking more satistics
for these objects, just not returning it.
Also add a checksum_last_failure column that holds the timestamptz of
the last checksum failure that occurred in a database (or in a
non-dataabase file), if any.
Author: Julien Rouhaud <rjuju123@gmail.com> M doc/src/sgml/monitoring.sgml
M doc/src/sgml/ref/initdb.sgml
M doc/src/sgml/ref/pg_basebackup.sgml
M src/backend/catalog/system_views.sql
M src/backend/postmaster/pgstat.c
M src/backend/replication/basebackup.c
M src/backend/utils/adt/pgstatfuncs.c
M src/include/catalog/pg_proc.dat
M src/include/pgstat.h
M src/test/regress/expected/rules.out
Fix REINDEX CONCURRENTLY of partitions
commit : ef6f30fe77af69a8c775cca82bf993b10c9889ee
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 12 Apr 2019 08:36:05 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 12 Apr 2019 08:36:05 +0200 In case of a partition index, when swapping the old and new index, we
also need to attach the new index as a partition and detach the old
one. Also, to handle partition indexes, we not only need to change
dependencies referencing the index, but also dependencies of the index
referencing something else. The previous code did this only
specifically for a constraint, but we also need to do this for
partitioned indexes. So instead write a generic function that does it
for all dependencies.
Author: Michael Paquier <michael@paquier.xyz>
Author: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/DF4PR8401MB11964EDB77C860078C343BEBEE5A0%40DF4PR8401MB1196.NAMPRD84.PROD.OUTLOOK.COM#154df1fedb735190a773481765f7b874 M src/backend/catalog/index.c
M src/backend/catalog/pg_depend.c
M src/include/catalog/dependency.h
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Fix GetNewTransactionId()’s interaction with xidVacLimit.
commit : f7feb020c3d8d5aff24204af28359b99ee65bf8f
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 12 Apr 2019 14:53:38 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 12 Apr 2019 14:53:38 +1200 Commit ad308058 switched to returning a FullTransactionId, but
failed to load the potentially updated value in the case where
xidVacLimit is reached and we release and reacquire the lock.
Repair, closing bug #15727.
While reviewing that commit, also fix the size computation used
by EstimateTransactionStateSize() and switch to the mul_size()
macro traditionally used in such expressions.
Author: Thomas Munro
Reported-by: Roman Zharkov
Discussion: https://postgr.es/m/15727-0be246e7d852d229%40postgresql.org M src/backend/access/transam/varsup.c
M src/backend/access/transam/xact.c
Fix typos in reloptions.c
commit : d87ab88686fb60ad5a34373de05bb20e632cf003
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 12 Apr 2019 12:56:38 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 12 Apr 2019 12:56:38 +0900 Author: Kirk Jamison
Discussion: https://postgr.es/m/D09B13F772D2274BB348A310EE3027C6493463@g01jpexmbkw24 M src/backend/access/common/reloptions.c
Switch TAP tests of pg_rewind to use a role with minimal permissions
commit : d4e2a843e6d6f325c070ee80a0c117ec11675e74
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 12 Apr 2019 10:46:43 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 12 Apr 2019 10:46:43 +0900 Up to now the tests of pg_rewind have been using a superuser for all the
tests (which is the default of many tests actually, and something that
ought to be reviewed) when involving an online source server, still it
is possible to use a non-superuser role to do that as long as this role
is granted permissions to execute all the source-side functions used for
the rewind. This is possible since v11, and was already documented as
of bfc8068.
This will allow to catch up easily any change in pg_rewind if the tool
begins to use more backend-side functions, so as the properties
introduced by v11 are kept.
Per suggestion from Peter Eisentraut.
Author: Michael Paquier
Reviewed-by: Magnus Hagander
Discussion: https://postgr.es/m/20190411041336.GM2728@paquier.xyz M src/bin/pg_rewind/t/RewindTest.pm
Fix more strcmp() calls using boolean-like comparisons for result checks
commit : d527fda6216780281b90f48820ae978c61c7905c
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 12 Apr 2019 10:16:49 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 12 Apr 2019 10:16:49 +0900 Such calls can confuse the reader as strcmp() uses an integer as result.
The places patched here have been spotted by Thomas Munro, David Rowley
and myself.
Author: Michael Paquier
Reviewed-by: David Rowley
Discussion: https://postgr.es/m/20190411021946.GG2728@paquier.xyz M contrib/spi/refint.c
M src/backend/commands/lockcmds.c
M src/backend/tsearch/spell.c
M src/test/modules/test_rls_hooks/test_rls_hooks.c
Re-order some regression test scripts for more parallelism.
commit : 798070ec058fe75757587c9e9916cc35c623f427
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 18:16:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 18:16:50 -0400 Move the strings, numerology, insert, insert_conflict, select and
errors tests to be parts of nearby parallel groups, instead of
executing by themselves. (Moving "select" required adjusting the
constraints test, which uses a table named "tmp" as select also
does. There don't seem to be any other conflicts.)
Move psql and stats_ext to the next parallel group, where the rules
test also has a long runtime. To make it safe to run stats_ext in
parallel with rules, I adjusted the latter to only dump views/rules
from the pg_catalog and public schemas, which was what it was doing
anyway. stats_ext makes some views in a transient schema, which now
will not affect rules.
Reorder serial_schedule to match parallel_schedule.
Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us M src/test/regress/expected/rules.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/input/constraints.source
M src/test/regress/output/constraints.source
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/rules.sql
Speed up sort-order-comparison tests in create_index_spgist.
commit : 5874c7055702e1cf5e58543f11dfcff6de2cc260
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 17:01:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 17:01:35 -0400 This test script verifies that KNN searches of an SP-GiST index
produce the same sort order as a seqscan-and-sort. The FULL JOINs
used for that are exceedingly slow, however. Investigation shows
that the problem is that the initial join is on the rank() values,
and we have a lot of duplicates due to the data set containing 1000
duplicate points. We're therefore going to produce 1000000 join
rows that have to be thrown away again by the join filter.
We can improve matters by using row_number() instead of rank(),
so that the initial join keys are unique. The catch is that
that makes the results sensitive to the sorting of rows with
equal distances from the reference point. That doesn't matter
for the actually-equal points, but as luck would have it, the
data set also contains two distinct points that have identical
distances to the origin. So those two rows could legitimately
appear in either order, causing unwanted output from the check
queries.
However, it doesn't seem like it's the job of this test to
check whether the <-> operator correctly computes distances;
its charter is just to verify that SP-GiST emits the values
in distance order. So we can dodge the indeterminacy problem
by having the check only compare row numbers and distances
not the actual point values.
This change reduces the run time of create_index_spgist by a good
three-quarters, on my machine, with ensuing beneficial effects on
the runtime of create_index (thanks to interactions with CREATE
INDEX CONCURRENTLY tests in the latter). I see a net improvement
of more than 2X in the runtime of their parallel test group.
Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us M src/test/regress/expected/create_index_spgist.out
M src/test/regress/sql/create_index_spgist.sql
Split up a couple of long-running regression test scripts.
commit : 385d396b807bdd7034ad3d0cea3c921d7cb04faa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 16:15:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 16:15:54 -0400 The point of this change is to increase the potential for parallelism
while running the core regression tests. Most people these days are
using parallel testing modes on multi-core machines, so we might as
well try a bit harder to keep multiple cores busy. Hence, a test that
runs much longer than others in its parallel group is a candidate to
be sub-divided.
In this patch, create_index.sql and join.sql are split up.
I haven't changed the content of the tests in any way, just
moved them.
I moved create_index.sql's SP-GiST-related tests into a new script
create_index_spgist, and moved its btree multilevel page deletion test
over to the existing script btree_index. (btree_index is a more natural
home for that test, and it's shorter than others in its parallel group,
so this doesn't hurt total runtime of that group.) There might be
room for more aggressive splitting of create_index, but this is enough
to improve matters considerably.
Likewise, I moved join.sql's "exercises for the hash join code" into
a new file join_hash. Those exercises contributed three-quarters of
the script's runtime. Which might well be excessive ... but for the
moment, I'm satisfied with shoving them into a different parallel
group, where they can share runtime with the roughly-equally-lengthy
gist test.
(Note for anybody following along at home: there are interesting
interactions between the runtimes of create_index and anything running
in parallel with it, because the tests of CREATE INDEX CONCURRENTLY
in that file will repeatedly block waiting for concurrent transactions
to commit. As committed in this patch, create_index and
create_index_spgist have roughly equal runtimes, but that's mostly an
artifact of forced synchronization of the CONCURRENTLY tests; when run
serially, create_index is much faster. A followup patch will reduce
the runtime of create_index_spgist and thereby also create_index.)
Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us M src/test/regress/expected/btree_index.out
M src/test/regress/expected/create_index.out
A src/test/regress/expected/create_index_spgist.out
M src/test/regress/expected/join.out
A src/test/regress/expected/join_hash.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/btree_index.sql
M src/test/regress/sql/create_index.sql
A src/test/regress/sql/create_index_spgist.sql
M src/test/regress/sql/join.sql
A src/test/regress/sql/join_hash.sql
Move plpgsql error-trapping tests to a new module-specific test file.
commit : 6726d8d476b424633ebdc7068da3f5a6e6da10af
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 15:09:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 15:09:18 -0400 The test for statement timeout has a 2-second timeout, which was only
moderately annoying when it was written, but nowadays it contributes
a pretty significant chunk of the elapsed time needed to run the core
regression tests on a fast machine. We can improve this situation by
pushing the test into a plpgsql-specific test file instead of having
it in a core regression test. That's a clean win when considering
just the core tests. Even when considering check-world or a buildfarm
test run, we should come out ahead because the core tests get run
more times in those sequences.
Furthermore, since the plpgsql tests aren't currently parallelized,
it seems likely that the timing problems reflected in commit f1e671a0b
(which increased that timeout from 1 sec to 2) will be much less severe
in this context. Hence, let's try cutting the timeout back to 1 second
in hopes of a further win for check-world. We can undo that if
buildfarm experience proves it to be a bad idea.
To give the new test file some modicum of intellectual coherency,
I moved the surrounding tests related to error-trapping along with
the statement timeout test proper. Those other tests don't run long
enough to have any particular bearing on test-runtime considerations.
The tests are the same as before, except with minor adjustments to
not depend on an externally-created table.
Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us M src/pl/plpgsql/src/Makefile
A src/pl/plpgsql/src/expected/plpgsql_trap.out
A src/pl/plpgsql/src/sql/plpgsql_trap.sql
M src/test/regress/expected/plpgsql.out
M src/test/regress/sql/plpgsql.sql
Fix off-by-one check that can lead to a memory overflow in ecpg.
commit : ed16ba3248d486ec8b2fdfc75e442620d675b617
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 11 Apr 2019 20:56:17 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 11 Apr 2019 20:56:17 +0200 Patch by Liu Huailing <liuhuailing@cn.fujitsu.com> M src/interfaces/ecpg/preproc/pgc.l
Remove duplicative polygon SP-GiST sequencing test.
commit : 4aaa3b5cf1c33d713b8eefa3612a9112cbcf1074
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 14:35:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 14:35:47 -0400 Code coverage comparisons confirm that the tests using
quad_poly_tbl_ord_seq1/quad_poly_tbl_ord_idx1 hit no code
paths not also covered by the similar tests using
quad_poly_tbl_ord_seq2/quad_poly_tbl_ord_idx2. Since these
test cases are pretty expensive, they need to contribute more
than zero benefit.
In passing, make quad_poly_tbl_ord_seq2 a temp table, since
there seems little reason to keep it around after the test.
Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us M src/test/regress/expected/polygon.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/sql/polygon.sql
doc: adjust libpq wording to be neither/nor
commit : d4888a3f766a7c02a9330c658c76c60e1ab8cc3e
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 11 Apr 2019 13:25:34 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 11 Apr 2019 13:25:34 -0400 Reported-by: postgresql@cohi.at
Discussion: https://postgr.es/m/155419437926.737.10876947446993402227@wrigleys.postgresql.org
Backpatch-through: 9.4 M doc/src/sgml/libpq.sgml
Remove redundant and ineffective test for btree insertion fast path.
commit : f72d9a5e7dda5f89336a60e8b720ef9964a67177
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 13:15:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 11 Apr 2019 13:15:59 -0400 indexing.sql's test for this feature was added along with the
feature in commit 2b2727343. However, shortly later that test was
rendered ineffective by commit 074251db6, which limited when the
optimization would be applied, so that the test didn't test it.
Since then, commit dd299df81 added new tests (in btree_index.sql)
that actually do test the feature. Code coverage comparisons
confirm that this test sequence adds no meaningful coverage, and
it's rather expensive, accounting for nearly half of the runtime
of indexing.sql according to my measurements. So let's remove it.
Per advice from Peter Geoghegan.
Discussion: https://postgr.es/m/735.1554935715@sss.pgh.pa.us M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql
Fix declaration after statement
commit : 65d857d92c418d732e3531a3761a32f2e352cb35
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 10 Apr 2019 22:28:50 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 10 Apr 2019 22:28:50 -0400 This style is frowned upon. I inadvertently introduced one in commit
fe0e0b4fc7f0. (My compiler does not complain about it, even though
-Wdeclaration-after-statement is specified. Weird.)
Author: Masahiko Sawada M src/bin/pgbench/pgbench.c
Fix backwards test in operator_precedence_warning logic.
commit : 4cae471d1b6bec7493dcb2ca156382bef738f293
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Apr 2019 19:02:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Apr 2019 19:02:21 -0400 Warnings about unary minus might have been wrong. It's a bit
surprising that nobody noticed yet ... probably the precedence-warning
feature hasn't really been used much in the field.
Rikard Falkeborn
Discussion: https://postgr.es/m/CADRDgG6fzA8A2oeygUw4=o7ywo4kvz26NxCSgpq22nMD73Bx4Q@mail.gmail.com M src/backend/parser/parse_expr.c
pg_restore: Make not verbose by default
commit : 765525c8c2c6e55abe8c0cd43bf5c728926d76d4
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 10 Apr 2019 11:45:00 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 10 Apr 2019 11:45:00 +0200 This was accidentally changed in
cc8d41511721d25d557fc02a46c053c0a602fed0.
Reported-by: Christoph Berg <myon@debian.org> M src/bin/pg_dump/pg_restore.c
Avoid counting transaction stats for parallel worker cooperating transaction.
commit : bdf35744bdf70208fc4d0f4b76f7d4bce3cf326b
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 10 Apr 2019 08:24:15 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 10 Apr 2019 08:24:15 +0530 The transaction that is initiated by the parallel worker to cooperate
with the actual transaction started by the main backend to complete the
query execution should not be counted as a separate transaction. The
other internal transactions started and committed by the parallel worker
are still counted as separate transactions as we that is what we do in
other places like autovacuum.
This will partially fix the bloat in transaction stats due to additional
transactions performed by parallel workers. For a complete fix, we need to
decide how we want to show all the transactions that are started internally
for various operations and that is a matter of separate patch.
Reported-by: Haribabu Kommi
Author: Haribabu Kommi
Reviewed-by: Amit Kapila, Jamison Kirk and Rahila Syed
Backpatch-through: 9.6
Discussion: https://postgr.es/m/CAJrrPGc9=jKXuScvNyQ+VNhO0FZk7LLAShAJRyZjnedd2D61EQ@mail.gmail.com M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/postmaster/pgstat.c
M src/include/pgstat.h
Improve comment in sync.h.
commit : d614aae02e8f878438716b7fd2642b8240b3f2b3
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 10 Apr 2019 12:49:49 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 10 Apr 2019 12:49:49 +1200 Per off-list complaint from Andres Freund. M src/include/storage/sync.h
Fix typos.
commit : 255044889d419354b46a2bf8907b83507d695af5
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 10 Apr 2019 09:21:06 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 10 Apr 2019 09:21:06 +1200 M src/backend/executor/execTuples.c
Prevent inlining of multiply-referenced CTEs with outer recursive refs.
commit : 9476131278c7bfc435ad9a21fc8e981272ac0dd2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 9 Apr 2019 15:47:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 9 Apr 2019 15:47:26 -0400 This has to be prevented because inlining would result in multiple
self-references, which we don't support (and in fact that's disallowed
by the SQL spec, see statements about linearly vs. nonlinearly
recursive queries). Bug fix for commit 608b167f9.
Per report from Yaroslav Schekin (via Andrew Gierth)
Discussion: https://postgr.es/m/87wolmg60q.fsf@news-spur.riddles.org.uk M src/backend/optimizer/plan/subselect.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql
Fix typo
commit : 4dba0f6dc407f965924d6c1007ac1bb5cc209dde
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 9 Apr 2019 12:59:53 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 9 Apr 2019 12:59:53 -0400 M src/backend/replication/slotfuncs.c
Fix memory leak in pgbench
commit : fe0e0b4fc7f0cdc2333bda08b199422a1e77a551
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 9 Apr 2019 12:46:34 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 9 Apr 2019 12:46:34 -0400 Commit 25ee70511ec2 introduced a memory leak in pgbench: some PGresult
structs were not being freed during error bailout, because we're now
doing more PQgetResult() calls than previously. Since there's more
cleanup code outside the discard_response() routine than in it, refactor
the cleanup code, removing the routine.
This has little effect currently, since we abandon processing after
hitting errors, but if we ever get further pgbench features (such as
testing for serializable transactions), it'll matter.
Per Coverity.
Reviewed-by: Michaël Paquier M src/bin/pgbench/pgbench.c
Test some more cases with partitioned tables in EvalPlanQual.
commit : a2418f9e238794fcaaf00bbd5b8f953ca2856aa0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 9 Apr 2019 11:42:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 9 Apr 2019 11:42:53 -0400 We weren't testing anything involving EPQ on UPDATEs that move tuples
into different partitions. Depending on the implementation,
it might be that these cases aren't actually very interesting ...
but given our thin coverage of EPQ in general, I think it's a good
idea to have a test case.
Amit Langote, minor tweak by me
Discussion: https://postgr.es/m/7889df35-ad1a-691a-00e3-4d4b18f364e3@lab.ntt.co.jp M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
Define WIN32_STACK_RLIMIT throughout win32 and cygwin builds.
commit : ba3fb5d4fb9227719759740b6d7771e719c3318b
author : Noah Misch <noah@leadboat.com>
date : Tue, 9 Apr 2019 08:25:39 -0700
committer: Noah Misch <noah@leadboat.com>
date : Tue, 9 Apr 2019 08:25:39 -0700 The MSVC build system already did this, and commit
617dc6d299c957e2784320382b3277ede01d9c63 used it in a second file.
Back-patch to 9.4, like that commit.
Discussion: https://postgr.es/m/CAA8=A7_1SWc3+3Z=-utQrQFOtrj_DeohRVt7diA2tZozxsyUOQ@mail.gmail.com M src/backend/tcop/Makefile
M src/makefiles/Makefile.cygwin
M src/makefiles/Makefile.win32
Replace tabs with spaces in one .sql file
commit : 9efe068e48f09d915660576f5672bfa9f1c0eb53
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 9 Apr 2019 14:37:37 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 9 Apr 2019 14:37:37 +0200 Let's at least keep this consistent within the same file. M src/backend/catalog/system_views.sql
Fix example in comment.
commit : 16954e22e2a881a4a5ead82f364635bfa63cc9df
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 9 Apr 2019 08:32:02 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 9 Apr 2019 08:32:02 +0300 Author: Adrien Nayrat M src/backend/lib/integerset.c
Avoid “could not reattach” by providing space for concurrent allocation.
commit : 617dc6d299c957e2784320382b3277ede01d9c63
author : Noah Misch <noah@leadboat.com>
date : Mon, 8 Apr 2019 21:39:00 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 8 Apr 2019 21:39:00 -0700 We've long had reports of intermittent "could not reattach to shared
memory" errors on Windows. Buildfarm member dory fails that way when
PGSharedMemoryReAttach() execution overlaps with creation of a thread
for the process's "default thread pool". Fix that by providing a second
region to receive asynchronous allocations that would otherwise intrude
into UsedShmemSegAddr. In pgwin32_ReserveSharedMemoryRegion(), stop
trying to free reservations landing at incorrect addresses; the caller's
next step has been to terminate the affected process. Back-patch to 9.4
(all supported versions).
Reviewed by Tom Lane. He also did much of the prerequisite research;
see commit bcbf2346d69f6006f126044864dd9383d50d87b4.
Discussion: https://postgr.es/m/20190402135442.GA1173872@rfd.leadboat.com M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/include/storage/pg_shmem.h
tableam: comment and formatting fixes.
commit : 6421011ea24db3a59dc7a0058a03e91981d53635
author : Andres Freund <andres@anarazel.de>
date : Mon, 8 Apr 2019 10:25:16 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 8 Apr 2019 10:25:16 -0700 Author: Heikki Linnakangas
Discussion: https://postgr.es/m/9a7fb9cc-2419-5db7-8840-ddc10c93f122@iki.fi M src/include/access/tableam.h
doc: Fix whitespace
commit : 122fa9f942478f8fdcfba961e01d172574369293
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 Apr 2019 22:27:35 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 Apr 2019 22:27:35 +0200 Author: Julien Rouhaud <rjuju123@gmail.com> M doc/src/sgml/client-auth.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/high-availability.sgml
M doc/src/sgml/json.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/parallel.sgml
M doc/src/sgml/postgres-fdw.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/ref/pg_basebackup.sgml
M doc/src/sgml/ref/pg_rewind.sgml
M doc/src/sgml/ref/pgupgrade.sgml
M doc/src/sgml/runtime.sgml
M doc/src/sgml/spgist.sgml
Fix improper interaction of FULL JOINs with lateral references.
commit : 45f8eaa8e3031c9cb12deb1b5e294bc052b378f2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Apr 2019 16:09:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Apr 2019 16:09:06 -0400 join_is_legal() needs to reject forming certain outer joins in cases
where that would lead the planner down a blind alley. However, it
mistakenly supposed that the way to handle full joins was to treat them
as applying the same constraints as for left joins, only to both sides.
That doesn't work, as shown in bug #15741 from Anthony Skorski: given
a lateral reference out of a join that's fully enclosed by a full join,
the code would fail to believe that any join ordering is legal, resulting
in errors like "failed to build any N-way joins".
However, we don't really need to consider full joins at all for this
purpose, because we effectively force them to be evaluated in syntactic
order, and that order is always legal for lateral references. Hence,
get rid of this broken logic for full joins and just ignore them instead.
This seems to have been an oversight in commit 7e19db0c0.
Back-patch to all supported branches, as that was.
Discussion: https://postgr.es/m/15741-276f1f464b3f40eb@postgresql.org M src/backend/optimizer/path/joinrels.c
M src/test/regress/expected/rangefuncs.out
M src/test/regress/sql/rangefuncs.sql
doc: Update serial explanation
commit : c66000385fe1dc94a6d5525dcd192f17b551fb9b
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 Apr 2019 22:03:48 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 Apr 2019 22:03:48 +0200 The CREATE SEQUENCE command should include a data type specification,
since PostgreSQL 10.
Reported-by: mjf@pearson.co.uk M doc/src/sgml/datatype.sgml
Fix EvalPlanQualStart to handle partitioned result rels correctly.
commit : a8cb8f124679e0c373fdd07108b136e1cf1ee14a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Apr 2019 12:20:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 8 Apr 2019 12:20:22 -0400 The es_root_result_relations array needs to be shallow-copied in the
same way as the main es_result_relations array, else EPQ rechecks on
partitioned result relations fail, as seen in bug #15677 from
Norbert Benkocs.
Amit Langote, isolation test case added by me
Discussion: https://postgr.es/m/15677-0bf089579b4cd02d@postgresql.org
Discussion: https://postgr.es/m/19321.1554567786@sss.pgh.pa.us M src/backend/executor/execMain.c
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
doc: Add note about generated columns in foreign tables
commit : 348f57ce5be96190491e2153abb47060884f8ebf
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 Apr 2019 13:47:46 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 Apr 2019 13:47:46 +0200 Explain that it is not enforced that querying a generated column
returns data that is consistent with the data that was stored. This
is similar to the note about constraints nearby.
Reported-by: Amit Langote <amitlangote09@gmail.com> M doc/src/sgml/ref/create_foreign_table.sgml
Add vacuum_truncate reloption.
commit : 119dcfad988d5b5d9f52b256087869997670aa36
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 8 Apr 2019 16:43:57 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 8 Apr 2019 16:43:57 +0900 vacuum_truncate controls whether vacuum tries to truncate off
any empty pages at the end of the table. Previously vacuum always
tried to do the truncation. However, the truncation could cause
some problems; for example, ACCESS EXCLUSIVE lock needs to
be taken on the table during the truncation and can cause
the query cancellation on the standby even if hot_standby_feedback
is true. Setting this reloption to false can be helpful to avoid
such problems.
Author: Tsunakawa Takayuki
Reviewed-By: Julien Rouhaud, Masahiko Sawada, Michael Paquier, Kirk Jamison and Fujii Masao
Discussion: https://postgr.es/m/CAHGQGwE5UqFqSq1=kV3QtTUtXphTdyHA-8rAj4A=Y+e4kyp3BQ@mail.gmail.com M doc/src/sgml/ref/create_table.sgml
M src/backend/access/common/reloptions.c
M src/backend/access/heap/vacuumlazy.c
M src/bin/psql/tab-complete.c
M src/include/utils/rel.h
M src/test/regress/expected/reloptions.out
M src/test/regress/sql/reloptions.sql
Tweak wording of documentation for pg_checksums
commit : e3865c37544d77bd4205dd5361592797b97d1e93
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 8 Apr 2019 15:30:45 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 8 Apr 2019 15:30:45 +0900 Author: Justin Pryzby
Discussion: https://postgr.es/m/20190329143210.GI5815@telsasoft.com M doc/src/sgml/ref/pg_checksums.sgml
Reset memory context once per tuple in validateForeignKeyConstraint.
commit : 4c9e1bd0a37e7b79dfc797dd91627336e871c1b0
author : Andres Freund <andres@anarazel.de>
date : Sun, 7 Apr 2019 22:42:42 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 7 Apr 2019 22:42:42 -0700 When using tableam ExecFetchSlotHeapTuple() might return a separately
allocated tuple. We could use the shouldFree argument to explicitly
free it, but it seems more robust to to protect
Also add a CHECK_FOR_INTERRUPTS() after each tuple. It's likely that
each AM has (heap does) a CFI somewhere in the relevant path, but it
seems more robust to have one in validateForeignKeyConstraint()
itself.
Note that this only affects the cases that couldn't be optimized to be
verified with a query.
Author: Andres Freund
Reviewed-By: Tom Lane (in an earlier version)
Discussion:
https://postgr.es/m/19030.1554574075@sss.pgh.pa.us
https://postgr.es/m/CAKJS1f_SHKcPYMsi39An5aUjhAcEMZb6Cx1Sj1QWEWSiKJkBVQ@mail.gmail.com
https://postgr.es/m/20180711185628.mrvl46bjgk2uxoki@alap3.anarazel.de M src/backend/commands/tablecmds.c
Fix a number of issues around modifying a previously updated row.
commit : 41f5e04aec6cf63ba8392adf70e9289e9c3706d6
author : Andres Freund <andres@anarazel.de>
date : Sun, 7 Apr 2019 22:14:47 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 7 Apr 2019 22:14:47 -0700 This commit fixes three, unfortunately related, issues:
1) Since 5db6df0c01, the introduction of DML via tableam, it was
possible to trigger "ERROR: unexpected table_lock_tuple status: 1"
when updating a row that was previously updated in the same
transaction - but only when the previously updated row was before
updated in a concurrent transaction (and READ COMMITTED was
used). The reason for that was that that case simply wasn't
expected. Fixing that lead to:
2) Even before the above commit, there were error checks (introduced
in 6868ed7491b7) preventing a row being updated by different
commands within the same statement (say in a function called by an
UPDATE) - but that check wasn't performed when the row was first
updated in a concurrent transaction - instead the second update was
silently skipped in that case. After this change we throw the same
error as we'd without the concurrent transaction.
3) The error messages (introduced in 6868ed7491b7) preventing such
updates emitted the same error message for both DELETE and
UPDATE ("tuple to be updated was already modified by an operation
triggered by the current command"). While that could be changed
separately, it made it hard to write tests that verify the correct
correct behavior of the code.
This commit changes heap's implementation of table_lock_tuple() to
return TM_SelfModified instead of TM_Invisible (previously loosely
modeled after EvalPlanQualFetch), and teaches nodeModifyTable.c to
handle that in response to table_lock_tuple() and not just in response
to table_(delete|update).
Additionally it fixes the wrong error message (see 3 above). The
comment for table_lock_tuple() is also adjusted to state that
TM_Deleted won't return information in TM_FailureData - it'll not
always be available.
This also adds tests to ensure that DELETE/UPDATE correctly error out
when affecting a row that concurrently was modified by another
transaction.
Author: Andres Freund
Reported-By: Tom Lane, when investigating a bug bug fix to another bug
by Amit Langote
Discussion: https://postgr.es/m/19321.1554567786@sss.pgh.pa.us M src/backend/access/heap/heapam_handler.c
M src/backend/executor/nodeModifyTable.c
M src/include/access/tableam.h
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
M src/test/regress/expected/triggers.out
Add more tests for partition tuple routing with dropped attributes
commit : 964bae4d8456e5406753027fa5a70181ddb4c835
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 8 Apr 2019 13:44:55 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 8 Apr 2019 13:44:55 +0900 As bug #15733 has proved, we are lacking coverage for partition tuple
routing with dropped attributes when involving three levels of
partitioning or more. There was only an active bug in this area for
v11, and HEAD is proving to handle those scenarios fine, still it lacked
some coverage for the previous problem.
Author: Amit Langote, Michael Paquier
Discussion: https://postgr.es/m/15733-7692379e310b80ec@postgresql.org M src/test/regress/expected/insert.out
M src/test/regress/sql/insert.sql
Avoid fetching past the end of the indoption array.
commit : 80a96e066eecb6bd1788964b5911a405d932a784
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Apr 2019 18:18:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Apr 2019 18:18:58 -0400 pg_get_indexdef_worker carelessly fetched indoption entries even for
non-key index columns that don't have one. 99.999% of the time this
would be harmless, since the code wouldn't examine the value ... but
some fine day this will be a fetch off the end of memory, resulting
in SIGSEGV.
Detected through valgrind testing. Odd that the buildfarm's valgrind
critters haven't noticed. M src/backend/utils/adt/ruleutils.c
psql \dP: list partitioned tables and indexes
commit : 1c5d9270e339662cdd78d51d0b859d4f0a11aa91
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 7 Apr 2019 07:59:12 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 7 Apr 2019 07:59:12 -0400 The new command lists partitioned relations (tables and/or indexes),
possibly with their sizes, possibly including partitioned partitions;
their parents (if not top-level); if indexes show the tables they belong
to; and their descriptions.
While there are various possible improvements to this, having it in this
form is already a great improvement over not having any way to obtain
this report.
Author: Pavel Stěhule, with help from Mathias Brossard, Amit Langote and
Justin Pryzby.
Reviewed-by: Amit Langote, Mathias Brossard, Melanie Plageman,
Michaël Paquier, Álvaro Herrera M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/command.c
M src/bin/psql/describe.c
M src/bin/psql/describe.h
M src/bin/psql/help.c
M src/bin/psql/tab-complete.c
M src/test/regress/expected/psql.out
M src/test/regress/sql/psql.sql
Clean up side-effects of commits ab5fcf2b0 et al.
commit : 159970bcadbbdefd312d75ce7ad90f19add19b40
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Apr 2019 12:54:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 7 Apr 2019 12:54:22 -0400 Before those commits, partitioning-related code in the executor could
assume that ModifyTableState.resultRelInfo[] contains only leaf partitions.
However, now a fully-pruned update results in a dummy ModifyTable that
references the root partitioned table, and that breaks some stuff.
In v11, this led to an assertion or core dump in the tuple routing code.
Fix by disabling tuple routing, since we don't need that anyway.
(I chose to do that in HEAD as well for safety, even though the problem
doesn't manifest in HEAD as it stands.)
In v10, this confused ExecInitModifyTable's decision about whether it
needed to close the root table. But we can get rid of that altogether
by being smarter about where to find the root table.
Note that since the referenced commits haven't shipped yet, this
isn't fixing any bug the field has seen.
Amit Langote, per a report from me
Discussion: https://postgr.es/m/20710.1554582479@sss.pgh.pa.us M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Report progress of REINDEX operations
commit : 03f9e5cba0ee1633af4abe734504df50af46fbd8
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 7 Apr 2019 11:30:14 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 7 Apr 2019 11:30:14 +0200 This uses the same infrastructure that the CREATE INDEX progress
reporting uses. Add a column to pg_stat_progress_create_index to
report the OID of the index being worked on. This was not necessary
for CREATE INDEX, but it's useful for REINDEX.
Also edit the phase descriptions a bit to be more consistent with the
source code comments.
Discussion: https://www.postgresql.org/message-id/ef6a6757-c36a-9e81-123f-13b19e36b7d7%402ndquadrant.com M doc/src/sgml/monitoring.sgml
M src/backend/catalog/index.c
M src/backend/catalog/system_views.sql
M src/backend/commands/indexcmds.c
M src/include/catalog/catversion.h
M src/include/commands/progress.h
M src/test/regress/expected/rules.out
Cast pg_stat_progress_cluster.cluster_index_relid to oid
commit : 106f2eb664bbd38c83090becff9fcde1e9622c9c
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 7 Apr 2019 10:31:32 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 7 Apr 2019 10:31:32 +0200 It's tracked internally as bigint, but when presented to the user it
should be oid. M doc/src/sgml/monitoring.sgml
M src/backend/catalog/system_views.sql
M src/include/catalog/catversion.h
M src/test/regress/expected/rules.out
Avoid Python memory leaks in hstore_plpython and jsonb_plpython.
commit : 9e360f0e8327bcf4b7c5ce957024fdff8f95f7de
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 6 Apr 2019 17:54:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 6 Apr 2019 17:54:29 -0400 Fix some places where we might fail to do Py_DECREF() on a Python
object (thereby leaking it for the rest of the session). Almost
all of the risks were in error-recovery paths, which we don't really
expect to hit anyway. Hence, while this is definitely a bug fix,
it doesn't quite seem worth back-patching.
Nikita Glukhov, Michael Paquier, Tom Lane
Discussion: https://postgr.es/m/28053a7d-10d8-fc23-b05c-b4749c873f63@postgrespro.ru M contrib/hstore_plpython/hstore_plpython.c
M contrib/jsonb_plpython/jsonb_plpython.c
Fix failures in validateForeignKeyConstraint’s slow path.
commit : 46e3442c9ec858071d60a1c0fae2e9868aeaa0c8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 6 Apr 2019 15:09:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 6 Apr 2019 15:09:09 -0400 The foreign-key-checking loop in ATRewriteTables failed to ignore
relations without storage (e.g., partitioned tables), unlike the
initial loop. This accidentally worked as long as RI_Initial_Check
succeeded, which it does in most practical cases (including all the
ones exercised in the existing regression tests :-(). However, if
that failed, as for instance when there are permissions issues,
then we entered the slow fire-the-trigger-on-each-tuple path.
And that would try to read from the referencing relation, and fail
if it lacks storage.
A second problem, recently introduced in HEAD, was that this loop
had been broken by sloppy refactoring for the tableam API changes.
Repair both issues, and add a regression test case so we have some
coverage on this code path. Back-patch as needed to v11.
(It looks like this code could do with additional bulletproofing,
but let's get a working test case in place first.)
Hadi Moshayedi, Tom Lane, Andres Freund
Discussion: https://postgr.es/m/CAK=1=WrnNmBbe5D9sm3t0a6dnAq3cdbF1vXY816j1wsMqzC8bw@mail.gmail.com
Discussion: https://postgr.es/m/19030.1554574075@sss.pgh.pa.us
Discussion: https://postgr.es/m/20190325180405.jytoehuzkeozggxx%40alap3.anarazel.de M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Add support TCP user timeout in libpq and the backend server
commit : 249d64999615802752940e017ee5166e726bc7cd
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 6 Apr 2019 15:23:37 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 6 Apr 2019 15:23:37 +0900 Similarly to the set of parameters for keepalive, a connection parameter
for libpq is added as well as a backend GUC, called tcp_user_timeout.
Increasing the TCP user timeout is useful to allow a connection to
survive extended periods without end-to-end connection, and decreasing
it allows application to fail faster. By default, the parameter is 0,
which makes the connection use the system default, and follows a logic
close to the keepalive parameters in its handling. When connecting
through a Unix-socket domain, the parameters have no effect.
Author: Ryohei Nagaura
Reviewed-by: Fabien Coelho, Robert Haas, Kyotaro Horiguchi, Kirk
Jamison, Mikalai Keida, Takayuki Tsunakawa, Andrei Yahorau
Discussion: https://postgr.es/m/EDA4195584F5064680D8130B1CA91C45367328@G01JPEXMBYT04 M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M doc/src/sgml/config.sgml
M doc/src/sgml/libpq.sgml
M src/backend/libpq/pqcomm.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
M src/include/libpq/libpq-be.h
M src/include/utils/guc.h
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/libpq-int.h
Use Append rather than MergeAppend for scanning ordered partitions.
commit : 959d00e9dbe4cfcf4a63bb655ac2c29a5e579246
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Apr 2019 19:20:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Apr 2019 19:20:30 -0400 If we need ordered output from a scan of a partitioned table, but
the ordering matches the partition ordering, then we don't need to
use a MergeAppend to combine the pre-ordered per-partition scan
results: a plain Append will produce the same results. This
both saves useless comparison work inside the MergeAppend proper,
and allows us to start returning tuples after istarting up just
the first child node not all of them.
However, all is not peaches and cream, because if some of the
child nodes have high startup costs then there will be big
discontinuities in the tuples-returned-versus-elapsed-time curve.
The planner's cost model cannot handle that (yet, anyway).
If we model the Append's startup cost as being just the first
child's startup cost, we may drastically underestimate the cost
of fetching slightly more tuples than are available from the first
child. Since we've had bad experiences with over-optimistic choices
of "fast start" plans for ORDER BY LIMIT queries, that seems scary.
As a klugy workaround, set the startup cost estimate for an ordered
Append to be the sum of its children's startup costs (as MergeAppend
would). This doesn't really describe reality, but it's less likely
to cause a bad plan choice than an underestimated startup cost would.
In practice, the cases where we really care about this optimization
will have child plans that are IndexScans with zero startup cost,
so that the overly conservative estimate is still just zero.
David Rowley, reviewed by Julien Rouhaud and Antonin Houska
Discussion: https://postgr.es/m/CAKJS1f-hAqhPLRk_RaSFTgYxd=Tz5hA7kQ2h4-DhJufQk8TGuw@mail.gmail.com M src/backend/executor/execProcnode.c
M src/backend/nodes/outfuncs.c
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/path/costsize.c
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/path/pathkeys.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/prep/prepunion.c
M src/backend/optimizer/util/pathnode.c
M src/backend/partitioning/partbounds.c
M src/include/nodes/pathnodes.h
M src/include/optimizer/pathnode.h
M src/include/optimizer/paths.h
M src/include/partitioning/partbounds.h
M src/test/regress/expected/inherit.out
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/inherit.sql
M src/test/regress/sql/partition_prune.sql
Add facility to copy replication slots
commit : 9f06d79ef831ffa333f908f6d3debdb654292414
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 Apr 2019 14:52:45 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 5 Apr 2019 14:52:45 -0300 This allows the user to create duplicates of existing replication slots,
either logical or physical, and even changing properties such as whether
they are temporary or the output plugin used.
There are multiple uses for this, such as initializing multiple replicas
using the slot for one base backup; when doing investigation of logical
replication issues; and to select a different output plugins.
Author: Masahiko Sawada
Reviewed-by: Michael Paquier, Andres Freund, Petr Jelinek
Discussion: https://postgr.es/m/CAD21AoAm7XX8y_tOPP6j4Nzzch12FvA1wPqiO690RCk+uYVstg@mail.gmail.com M contrib/test_decoding/expected/slot.out
M contrib/test_decoding/sql/slot.sql
M doc/src/sgml/func.sgml
M src/backend/replication/logical/logical.c
M src/backend/replication/slotfuncs.c
M src/backend/replication/walsender.c
M src/include/catalog/catversion.h
M src/include/catalog/pg_proc.dat
M src/include/replication/logical.h
Wake up interested backends when a checkpoint fails.
commit : de2b38419c4018fc8c2c917cc2cc752063096cfb
author : Thomas Munro <tmunro@postgresql.org>
date : Sat, 6 Apr 2019 09:31:48 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Sat, 6 Apr 2019 09:31:48 +1300 Commit c6c9474a switched to condition variables instead of sleep
loops to notify backends of checkpoint start and stop, but forgot
to broadcast in case of checkpoint failure.
Author: Thomas Munro
Discussion: https://postgr.es/m/CA%2BhUKGJKbCd%2B_K%2BSEBsbHxVT60SG0ivWHHAdvL0bLTUt2xpA2w%40mail.gmail.com M src/backend/postmaster/checkpointer.c
Fix missing word.
commit : 6665305e17edff3e2c43d71396ea5b6a69e7b6f3
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 5 Apr 2019 15:25:09 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 5 Apr 2019 15:25:09 -0400 Nathan Bossart
Discussion: http://postgr.es/m/2C63765B-AD31-4F6C-8DA7-C8544634C714@amazon.com M doc/src/sgml/ref/vacuum.sgml
Ensure consistent name matching behavior in processSQLNamePattern().
commit : 478cacb50e4851760db9b8e75b2256085b571965
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Apr 2019 12:59:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 5 Apr 2019 12:59:46 -0400 Prior to v12, if you used a collation-sensitive regex feature in a
pattern handled by processSQLNamePattern() (for instance, \d '\\w+'
in psql), the behavior you got matched the database's default collation.
Since commit 586b98fdf you'd usually get C-collation behavior, because
the catalog "name"-type columns are now marked as COLLATE "C". Add
explicit COLLATE specifications to restore the prior behavior.
(Note for whoever writes the v12 release notes: the need for this shows
that while 586b98fdf preserved pre-v12 behavior of "name" columns for
simple comparison operators, it changed the behavior of regex operators
on those columns. Although this patch fixes it for pattern matches
generated by our own tools, user-written queries will still be affected.
So we'd better mention this issue as a compatibility item.)
Daniel Vérité
Discussion: https://postgr.es/m/701e51f0-0ec0-4e70-a365-1958d66dd8d2@manitou-mail.org M src/fe_utils/string_utils.c
table: docs: fix typos and grammar.
commit : 86cc06d1cf9c30be3b79207242e6746f0f0b681c
author : Andres Freund <andres@anarazel.de>
date : Fri, 5 Apr 2019 09:45:59 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 5 Apr 2019 09:45:59 -0700 Author: Justin Pryzby
Discussion: https://postgr.es/m/20190404055138.GA24864@telsasoft.com M doc/src/sgml/catalogs.sgml
M doc/src/sgml/ref/select_into.sgml
M doc/src/sgml/storage.sgml
M doc/src/sgml/tableam.sgml
Doc: Update documentation on partitioning vs. foreign tables.
commit : 3e6b0c472942e9a73e0fc10659dce2cba56959a7
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 5 Apr 2019 20:55:06 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 5 Apr 2019 20:55:06 +0900 The limitations that it is not allowed to create/attach a foreign table
as a partition of an indexed partitioned table were not documented.
Reported-By: Stepan Yankevych
Author: Etsuro Fujita
Reviewed-By: Amit Langote
Backpatch-through: 11 where partitioned index was introduced
Discussion: https://postgr.es/m/1553869152.858391073.5f8m3n0x@frv53.fwdcdn.com M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/create_foreign_table.sgml
Fix compiler warning
commit : edda32ee250fe480701083d4e072e06929991bf9
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 5 Apr 2019 09:23:07 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 5 Apr 2019 09:23:07 +0200 Rewrite get_attgenerated() to avoid compiler warning if the compiler
does not recognize that elog(ERROR) does not return.
Reported-by: David Rowley <david.rowley@2ndquadrant.com> M src/backend/utils/cache/lsyscache.c
Revert “Consistently test for in-use shared memory.”
commit : 82150a05be0dc8a8ec708d1f6e6e1ef26c0e58d4
author : Noah Misch <noah@leadboat.com>
date : Fri, 5 Apr 2019 00:00:52 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 5 Apr 2019 00:00:52 -0700 This reverts commits 2f932f71d9f2963bbd201129d7b971c8f5f077fd,
16ee6eaf80a40007a138b60bb5661660058d0422 and
6f0e190056fe441f7cf788ff19b62b13c94f68f3. The buildfarm has revealed
several bugs. Back-patch like the original commits.
Discussion: https://postgr.es/m/20190404145319.GA1720877@rfd.leadboat.com M src/Makefile.global.in
M src/backend/port/sysv_shmem.c
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/ipci.c
M src/backend/utils/init/postinit.c
M src/include/storage/ipc.h
M src/include/storage/pg_shmem.h
M src/test/perl/PostgresNode.pm
D src/test/recovery/t/017_shm.pl
M src/tools/msvc/vcregress.pl
Fix bugs in mdsyncfiletag().
commit : 794c543b1736f71ff5bc5231eee41cdf460ad8ce
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 5 Apr 2019 16:39:47 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 5 Apr 2019 16:39:47 +1300 Commit 3eb77eba moved a _mdfd_getseg() call from mdsync() into a new
callback function mdsyncfiletag(), but didn't get the arguments quite
right. Without the EXTENSION_DONT_CHECK_SIZE flag we fail to open a
segment if lower-numbered segments have been truncated, and it wants
a block number rather than a segment number.
While comparing with the older coding, also remove an unnecessary
clobbering of errno, and adjust the code in mdunlinkfiletag() to
ressemble the original code from mdpostckpt() more closely instead
of using an unnecessary call to smgropen().
Author: Thomas Munro
Discussion: https://postgr.es/m/CA%2BhUKGL%2BYLUOA0eYiBXBfwW%2BbH5kFgh94%3DgQH0jHEJ-t5Y91wQ%40mail.gmail.com M src/backend/storage/smgr/md.c
Handle errors during GSSAPI startup better
commit : c46c85d4594d52fb34d36d4761bb9cfc5626f20b
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 4 Apr 2019 22:52:42 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 4 Apr 2019 22:52:42 -0400 There was some confusion over the format of the error message returned
from the server during GSSAPI startup; specifically, it was expected
that a length would be returned when, in reality, at this early stage in
the startup sequence, no length is returned from the server as part of
an error message.
Correct the client-side code for dealing with error messages sent by the
server during startup by simply reading what's available into our
buffer, after we've discovered it's an error message, and then reporting
back what was returned.
In passing, also add in documentation of the environment variable
PGGSSENCMODE which was missed previously, and adjust the code to look
for the PGGSSENCMODE variable (the environment variable change was
missed in the prior GSSMODE -> GSSENCMODE commit).
Error-handling issue discovered by Peter Eisentraut, the rest were items
discovered during testing of the error handling. M doc/src/sgml/libpq.sgml
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-secure-gssapi.c
Fix some documentation in pg_rewind
commit : bfc80683ce51590545350b2c8ccfaa9e7a2a1870
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 5 Apr 2019 10:37:59 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 5 Apr 2019 10:37:59 +0900 Since 11, it is possible to use a non-superuser role when using an
online source cluster with pg_rewind as long as the role has proper
permissions to execute on the source all the functions used by
pg_rewind, and the documentation stated that a superuser is necessary.
Let's add at the same time all the details needed to create such a
role.
A second confusion which comes a lot from users is that it is necessary
to issue a checkpoint on a freshly-promoted standby so as its control
file has up-to-date timeline information which is used by pg_rewind to
validate the operation. Let's document that properly. This is
back-patched down to 9.5 where pg_rewind has been introduced.
Author: Michael Paquier
Reviewed-by: Magnus Hagander
Discussion: https://postgr.es/m/CABUevEz5bpvbwVsYCaSMV80CBZ5-82nkMzbb+Bu=h1m=rLdn=g@mail.gmail.com
Backpatch-through: 9.5 M doc/src/sgml/ref/pg_rewind.sgml
Remove unused struct member, enforce multi_insert callback presence.
commit : 57a7a3adfe4eadb471bb45a7effb1a99ebb00a7b
author : Andres Freund <andres@anarazel.de>
date : Thu, 4 Apr 2019 17:36:45 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 4 Apr 2019 17:36:45 -0700 Author: David Rowley, Andres Freund
Discussion: https://postgr.es/m/CAKJS1f9=9phmm66diAji4gvHnWSrK7BGFoNct+mEUT_c8pPOjw@mail.gmail.com M src/backend/access/table/tableamapi.c
M src/backend/commands/copy.c
Harden tableam against nonexistant / wrong kind of AMs.
commit : ea97e440b8570ffd1a6cd6604f2ef882c0a72291
author : Andres Freund <andres@anarazel.de>
date : Thu, 4 Apr 2019 17:17:50 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 4 Apr 2019 17:17:50 -0700 Previously it was allowed to set default_table_access_method to an
empty string. That makes sense for default_tablespace, where that was
copied from, as it signals falling back to the database's default
tablespace. As there is no equivalent for table AMs, forbid that.
Also make sure to throw a usable error when creating a table using an
index AM, by using get_am_type_oid() to implement get_table_am_oid()
instead of a separate copy. Previously we'd error out only later, in
GetTableAmRoutine().
Thirdly remove GetTableAmRoutineByAmId() - it was only used in an
earlier version of 8586bf7ed8.
Add tests for the above (some for index AMs as well). M src/backend/access/table/tableamapi.c
M src/backend/commands/amcmds.c
M src/backend/commands/tablecmds.c
M src/include/access/tableam.h
M src/include/commands/defrem.h
M src/test/regress/expected/create_am.out
M src/test/regress/expected/type_sanity.out
M src/test/regress/sql/create_am.sql
M src/test/regress/sql/type_sanity.sql
Add test coverage for rootdescend verification.
commit : 344b7e11bbaf5e11f2497b11405e63d190043cfe
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 4 Apr 2019 17:25:35 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 4 Apr 2019 17:25:35 -0700 Commit c1afd175, which added support for rootdescend verification to
amcheck, added only minimal regression test coverage. Address this by
making sure that rootdescend verification is run on a multi-level index.
In passing, simplify some of the regression tests that exercise
multi-level nbtree page deletion.
Both issues spotted while rereviewing coverage of the nbtree patch
series using gcov. M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
tableam: Add table_multi_insert() and revamp/speed-up COPY FROM buffering.
commit : 86b85044e823a304d2a265abc030254d39efe7df
author : Andres Freund <andres@anarazel.de>
date : Thu, 4 Apr 2019 15:47:19 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 4 Apr 2019 15:47:19 -0700 This adds table_multi_insert(), and converts COPY FROM, the only user
of heap_multi_insert, to it.
A simple conversion of COPY FROM use slots would have yielded a
slowdown when inserting into a partitioned table for some
workloads. Different partitions might need different slots (both slot
types and their descriptors), and dropping / creating slots when
there's constant partition changes is measurable.
Thus instead revamp the COPY FROM buffering for partitioned tables to
allow to buffer inserts into multiple tables, flushing only when
limits are reached across all partition buffers. By only dropping
slots when there've been inserts into too many different partitions,
the aforementioned overhead is gone. By allowing larger batches, even
when there are frequent partition changes, we actuall speed such cases
up significantly.
By using slots COPY of very narrow rows into unlogged / temporary
might slow down very slightly (due to the indirect function calls).
Author: David Rowley, Andres Freund, Haribabu Kommi
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20190327054923.t3epfuewxfqdt22e@alap3.anarazel.de M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/commands/copy.c
M src/backend/executor/execMain.c
M src/backend/executor/execPartition.c
M src/include/access/heapam.h
M src/include/access/tableam.h
M src/include/nodes/execnodes.h
M src/tools/pgindent/typedefs.list
Add a “SQLSTATE-only” error verbosity option to libpq and psql.
commit : 7bac3acab4d5c3f2c35aa3a7bea08411d83fd5bc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 Apr 2019 17:22:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 Apr 2019 17:22:02 -0400 This is intended for use mostly in test scripts for external tools,
which could do without cross-PG-version variations in error message
wording. Of course, the SQLSTATE isn't guaranteed stable either, but
it should be more so than the error message text.
Note: there's a bit of an ABI change for libpq here, but it seems
OK because if somebody compiles against a newer version of libpq-fe.h,
and then tries to pass PQERRORS_SQLSTATE to PQsetErrorVerbosity()
of an older libpq library, it will be accepted and then act like
PQERRORS_DEFAULT, thanks to the way the tests in pqBuildErrorMessage3
have historically been phrased. That seems acceptable.
Didier Gautheron, reviewed by Dagfinn Ilmari Mannsåker
Discussion: https://postgr.es/m/CAJRYxuKyj4zA+JGVrtx8OWAuBfE-_wN4sUMK4H49EuPed=mOBw@mail.gmail.com M doc/src/sgml/libpq.sgml
M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/help.c
M src/bin/psql/startup.c
M src/bin/psql/tab-complete.c
M src/interfaces/libpq/fe-protocol3.c
M src/interfaces/libpq/libpq-fe.h
M src/test/regress/expected/psql.out
M src/test/regress/sql/psql.sql
pg_restore: Require “-f -” to mean stdout
commit : 413ccaa74d9a126b042727c826e65e2844adadac
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 4 Apr 2019 16:34:58 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 4 Apr 2019 16:34:58 -0300 The previous convention that stdout was selected by default when nothing
is specified was just too error-prone.
After a suggestion from Andrew Gierth.
Author: Euler Taveira
Reviewed-by: Yoshikazu Imai, José Arthur Benetasso Villanova
Discussion: https://postgr.es/m/87sgwrmhdv.fsf@news-spur.riddles.org.uk M doc/src/sgml/ref/pg_restore.sgml
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_restore.c
M src/bin/pg_dump/t/001_basic.pl
Make queries’ locking of indexes more consistent.
commit : 9c703c169a872d144f2f79d2fb211c82587adfa7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 Apr 2019 15:12:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 4 Apr 2019 15:12:51 -0400 The assertions added by commit b04aeb0a0 exposed that there are some
code paths wherein the executor will try to open an index without
holding any lock on it. We do have some lock on the index's table,
so it seems likely that there's no fatal problem with this (for
instance, the index couldn't get dropped from under us). Still,
it's bad practice and we should fix it.
To do so, remove the optimizations in ExecInitIndexScan and friends
that tried to avoid taking a lock on an index belonging to a target
relation, and just take the lock always. In non-bug cases, this
will result in no additional shared-memory access, since we'll find
in the local lock table that we already have a lock of the desired
type; hence, no significant performance degradation should occur.
Also, adjust the planner and executor so that the type of lock taken
on an index is always identical to the type of lock taken for its table,
by relying on the recently added RangeTblEntry.rellockmode field.
This avoids some corner cases where that might not have been true
before (possibly resulting in extra locking overhead), and prevents
future maintenance issues from having multiple bits of logic that
all needed to be in sync. In addition, this change removes all core
calls to ExecRelationIsTargetRelation, which avoids a possible O(N^2)
startup penalty for queries with large numbers of target relations.
(We'd probably remove that function altogether, were it not that we
advertise it as something that FDWs might want to use.)
Also adjust some places in selfuncs.c to not take any lock on indexes
they are transiently opening, since we can assume that plancat.c
did that already.
In passing, change gin_clean_pending_list() to take RowExclusiveLock
not AccessShareLock on its target index. Although it's not clear that
that's actually a bug, it seemed very strange for a function that's
explicitly going to modify the index to use only AccessShareLock.
David Rowley, reviewed by Julien Rouhaud and Amit Langote,
a bit of further tweaking by me
Discussion: https://postgr.es/m/19465.1541636036@sss.pgh.pa.us M src/backend/access/gin/ginfast.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeBitmapIndexscan.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/executor/nodeIndexscan.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/util/plancat.c
M src/backend/utils/adt/selfuncs.c
Allow VACUUM to be run with index cleanup disabled.
commit : a96c41feec6b6616eb9d5baee9a9e08c20533c38
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 4 Apr 2019 14:58:53 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 4 Apr 2019 14:58:53 -0400 This commit adds a new reloption, vacuum_index_cleanup, which
controls whether index cleanup is performed for a particular
relation by default. It also adds a new option to the VACUUM
command, INDEX_CLEANUP, which can be used to override the
reloption. If neither the reloption nor the VACUUM option is
used, the default is true, as before.
Masahiko Sawada, reviewed and tested by Nathan Bossart, Alvaro
Herrera, Kyotaro Horiguchi, Darafei Praliaskouski, and me.
The wording of the documentation is mostly due to me.
Discussion: http://postgr.es/m/CAD21AoAt5R3DNUZSjOoXDUY=naYPUOuffVsRzuTYMz29yLzQCA@mail.gmail.com M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/ref/vacuum.sgml
M src/backend/access/common/reloptions.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/commands/vacuum.c
M src/backend/postmaster/autovacuum.c
M src/bin/psql/tab-complete.c
M src/include/commands/vacuum.h
M src/include/utils/rel.h
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Invalidate binary search bounds consistently.
commit : 74eb2176bf3ac7a2fae1282b4f4f1d000f3e6d78
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 4 Apr 2019 09:38:08 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 4 Apr 2019 09:38:08 -0700 _bt_check_unique() failed to invalidate binary search bounds in the
event of a live conflict following commit e5adcb78. This resulted in
problems after waiting for the conflicting xact to commit or abort. The
subsequent call to _bt_check_unique() would restore the initial binary
search bounds, rather than starting a new search. Fix by explicitly
invalidating bounds when it becomes clear that there is a live conflict
that insertion will have to wait to resolve.
Ashutosh Sharma, with a few additional tweaks by me.
Author: Ashutosh Sharma
Reported-By: Ashutosh Sharma
Diagnosed-By: Ashutosh Sharma
Discussion: https://postgr.es/m/CAE9k0PnQp-qr-UYKMSCzdC2FBzdE4wKP41hZrZvvP26dKLonLg@mail.gmail.com M src/backend/access/nbtree/nbtinsert.c
Move the be_gssapiget* prototypes
commit : 87e16db5ebe7256712999ec690899237029b9ae7
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 4 Apr 2019 11:11:46 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 4 Apr 2019 11:11:46 -0400 The be_gssapi_get_* prototypes were put close to similar ones for SSL-
but a bit too close since that meant they ended up only being included
for SSL-enabled builds. Move those to be under ENABLE_GSS instead.
Pointed out by Tom. M src/include/libpq/libpq-be.h
Refactor the fsync queue for wider use.
commit : 3eb77eba5a51780d5cf52cd66a9844cd4d26feb0
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 4 Apr 2019 21:56:03 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 4 Apr 2019 21:56:03 +1300 Previously, md.c and checkpointer.c were tightly integrated so that
fsync calls could be handed off and processed in the background.
Introduce a system of callbacks and file tags, so that other modules
can hand off fsync work in the same way.
For now only md.c uses the new interface, but other users are being
proposed. Since there may be use cases that are not strictly SMGR
implementations, use a new function table for sync handlers rather
than extending the traditional SMGR one.
Instead of using a bitmapset of segment numbers for each RelFileNode
in the checkpointer's hash table, make the segment number part of the
key. This requires sending explicit "forget" requests for every
segment individually when relations are dropped, but suits the file
layout schemes of proposed future users better (ie sparse or high
segment numbers).
Author: Shawn Debnath and Thomas Munro
Reviewed-by: Thomas Munro, Andres Freund
Discussion: https://postgr.es/m/CAEepm=2gTANm=e3ARnJT=n0h8hf88wqmaZxk0JYkxw+b21fNrw@mail.gmail.com M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/commands/dbcommands.c
M src/backend/postmaster/checkpointer.c
M src/backend/storage/Makefile
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/smgr/md.c
M src/backend/storage/smgr/smgr.c
A src/backend/storage/sync/Makefile
A src/backend/storage/sync/sync.c
M src/backend/utils/init/postinit.c
M src/include/postmaster/bgwriter.h
M src/include/storage/fd.h
A src/include/storage/md.h
M src/include/storage/smgr.h
A src/include/storage/sync.h
M src/tools/pgindent/typedefs.list
file_fdw: Fix for generated columns
commit : 33215d113d61980a4b2f2aec36cdcd21fa58c1c4
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 4 Apr 2019 09:24:48 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 4 Apr 2019 09:24:48 +0200 Since file_fdw uses COPY internally, but COPY doesn't allow listing
generated columns in its column list, we need to make sure that we
don't add generated columns to the column lists internally generated
by file_fdw.
Reported-by: Erik Rijkers <er@xs4all.nl> M contrib/file_fdw/file_fdw.c
M contrib/file_fdw/input/file_fdw.source
M contrib/file_fdw/output/file_fdw.source
Silence -Wimplicit-fallthrough in sysv_shmem.c.
commit : 6f0e190056fe441f7cf788ff19b62b13c94f68f3
author : Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 23:23:35 -0700
committer: Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 23:23:35 -0700 Commit 2f932f71d9f2963bbd201129d7b971c8f5f077fd added code that elicits
a warning on buildfarm member flaviventris. Back-patch to 9.4, like
that commit.
Reported by Andres Freund.
Discussion: https://postgr.es/m/20190404020057.galelv7by75ekqrh@alap3.anarazel.de M src/backend/port/sysv_shmem.c
Make src/test/recovery/t/017_shm.pl safe for concurrent execution.
commit : 16ee6eaf80a40007a138b60bb5661660058d0422
author : Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 23:16:37 -0700
committer: Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 23:16:37 -0700 Buildfarm members idiacanthus and komodoensis, which share a host, both
executed this test in the same second. That failed. Back-patch to 9.6,
where the test first appeared.
Discussion: https://postgr.es/m/20190404020543.GA1319573@rfd.leadboat.com M src/test/recovery/t/017_shm.pl
Improve readability of some tests in strings.sql
commit : 92c76021aed47daa61afd5c7d6f8201382dee203
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 4 Apr 2019 10:24:56 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 4 Apr 2019 10:24:56 +0900 c251336 has added some tests to check if a toast relation should be
empty or not, hardcoding the toast relation name when calling
pg_relation_size(). pg_class.reltoastrelid offers the same information,
so simplify the tests to use that.
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/20190403065949.GH3298@paquier.xyz M src/test/regress/expected/strings.out
M src/test/regress/sql/strings.sql
tableam: basic documentation.
commit : b73c3a11963c8bb783993cfffabb09f558f86e37
author : Andres Freund <andres@anarazel.de>
date : Wed, 3 Apr 2019 17:37:00 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 3 Apr 2019 17:37:00 -0700 This adds documentation about the user oriented parts of table access
methods (i.e. the default_table_access_method GUC and the USING clause
for CREATE TABLE etc), adds a basic chapter about the table access
method interface, and adds a note to storage.sgml that it's contents
don't necessarily apply for non-builtin AMs.
Author: Haribabu Kommi and Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M doc/src/sgml/catalogs.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/filelist.sgml
M doc/src/sgml/indexam.sgml
M doc/src/sgml/postgres.sgml
M doc/src/sgml/ref/create_access_method.sgml
M doc/src/sgml/ref/create_materialized_view.sgml
M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/ref/create_table_as.sgml
M doc/src/sgml/ref/select_into.sgml
M doc/src/sgml/storage.sgml
A doc/src/sgml/tableam.sgml
M src/include/access/tableam.h
Assert that pgwin32_signal_initialize() has been called early enough.
commit : ab9ed9be2378f02edf613e0543a29287e7484338
author : Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 17:11:16 -0700
committer: Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 17:11:16 -0700 Before the pgwin32_signal_initialize() call, the backend version of
pg_usleep() has no effect. No in-tree code falls afoul of that today,
but temporary commit 23078689a9921968ac0873b017be6e7f772f10bc did so.
Discussion: https://postgr.es/m/20190402135442.GA1173872@rfd.leadboat.com M src/backend/port/win32/signal.c
M src/port/open.c
Handle USE_MODULE_DB for all tests able to use an installed postmaster.
commit : f433394e48afbb733b1436276a5a08cd78443164
author : Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 17:06:01 -0700
committer: Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 17:06:01 -0700 When $(MODULES) and $(MODULE_big) are empty, derive the database name
from the first element of $(REGRESS) instead of using a constant string.
When deriving the database name from $(MODULES), use its first element
instead of the entire list; the earlier approach would fail if any
multi-module directory had $(REGRESS) tests. Treat isolation suites and
src/pl correspondingly. Under USE_MODULE_DB=1, installcheck-world and
check-world no longer reuse any database name in a given postmaster.
Buildfarm members axolotl, mandrill and frogfish saw spurious "is being
accessed by other users" failures that would not have happened without
database name reuse. (The CountOtherDBBackends() 5s deadline expired
during DROP DATABASE; a backend for an earlier test suite had used the
same database name and had not yet exited.) Back-patch to 9.4 (all
supported versions), except bits pertaining to isolation suites.
Concept reviewed by Andrew Dunstan, Andres Freund and Tom Lane.
Discussion: https://postgr.es/m/20190401135213.GE891537@rfd.leadboat.com M src/Makefile.global.in
M src/makefiles/pgxs.mk
Consistently test for in-use shared memory.
commit : 2f932f71d9f2963bbd201129d7b971c8f5f077fd
author : Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 17:03:46 -0700
committer: Noah Misch <noah@leadboat.com>
date : Wed, 3 Apr 2019 17:03:46 -0700 postmaster startup scrutinizes any shared memory segment recorded in
postmaster.pid, exiting if that segment matches the current data
directory and has an attached process. When the postmaster.pid file was
missing, a starting postmaster used weaker checks. Change to use the
same checks in both scenarios. This increases the chance of a startup
failure, in lieu of data corruption, if the DBA does "kill -9 `head -n1
postmaster.pid` && rm postmaster.pid && pg_ctl -w start". A postmaster
will no longer recycle segments pertaining to other data directories.
That's good for production, but it's bad for integration tests that
crash a postmaster and immediately delete its data directory. Such a
test now leaks a segment indefinitely. No "make check-world" test does
that. win32_shmem.c already avoided all these problems. In 9.6 and
later, enhance PostgresNode to facilitate testing. Back-patch to 9.4
(all supported versions).
Reviewed by Daniel Gustafsson and Kyotaro HORIGUCHI.
Discussion: https://postgr.es/m/20130911033341.GD225735@tornado.leadboat.com M src/Makefile.global.in
M src/backend/port/sysv_shmem.c
M src/backend/port/win32_shmem.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/ipc/ipci.c
M src/backend/utils/init/postinit.c
M src/include/storage/ipc.h
M src/include/storage/pg_shmem.h
M src/test/perl/PostgresNode.pm
A src/test/recovery/t/017_shm.pl
M src/tools/msvc/vcregress.pl
Doc: clarify partial-index example.
commit : af052daec5aa282eab2d22fa3b24d6109a30c2f3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 Apr 2019 18:28:18 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 Apr 2019 18:28:18 -0400 Jonathan Katz
Discussion: https://postgr.es/m/155432280882.722.12392985690846288230@wrigleys.postgresql.org M doc/src/sgml/indices.sgml
Add SETTINGS option to EXPLAIN, to print modified settings.
commit : ea569d64ac7174d3fe657e3e682d11053ecf1866
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 4 Apr 2019 00:04:31 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 4 Apr 2019 00:04:31 +0200 Query planning is affected by a number of configuration options, and it
may be crucial to know which of those options were set to non-default
values. With this patch you can say EXPLAIN (SETTINGS ON) to include
that information in the query plan. Only options affecting planning,
with values different from the built-in default are printed.
This patch also adds auto_explain.log_settings option, providing the
same capability in auto_explain module.
Author: Tomas Vondra
Reviewed-by: Rafia Sabih, John Naylor
Discussion: https://postgr.es/m/e1791b4c-df9c-be02-edc5-7c8874944be0@2ndquadrant.com M contrib/auto_explain/auto_explain.c
M doc/src/sgml/auto-explain.sgml
M doc/src/sgml/ref/explain.sgml
M src/backend/commands/explain.c
M src/backend/utils/misc/guc.c
M src/include/commands/explain.h
M src/include/utils/guc.h
M src/include/utils/guc_tables.h
Tweak docs for log_statement_sample_rate
commit : d1f04b96b99d595e80791cdb0faa9cfdde2a5afa
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Apr 2019 18:54:02 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Apr 2019 18:54:02 -0300 Author: Justin Pryzby, partly after a suggestion from Masahiko Sawada
Discussion: https://postgr.es/m/20190328135918.GA27808@telsasoft.com
Discussion: https://postgr.es/m/CAD21AoB9+y8N4+Fan-ne-_7J5yTybPttxeVKfwUocKp4zT1vNQ@mail.gmail.com M doc/src/sgml/config.sgml
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
Log all statements from a sample of transactions
commit : 799e220346f1387e823a4dbdc3b1c8c3cdc5c3e0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Apr 2019 18:43:59 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Apr 2019 18:43:59 -0300 This is useful to obtain a view of the different transaction types in an
application, regardless of the durations of the statements each runs.
Author: Adrien Nayrat
Reviewed-by: Masahiko Sawada, Hayato Kuroda, Andres Freund M doc/src/sgml/config.sgml
M src/backend/access/transam/xact.c
M src/backend/tcop/postgres.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
M src/include/access/xact.h
M src/include/utils/guc.h
Remove now-unnecessary thread pointer arguments in pgbench.
commit : d8c0bd9fefa9c70a3f5613fba672fa92f08ea940
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 Apr 2019 17:16:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 Apr 2019 17:16:00 -0400 Not required after nuking the zipfian thread-local cache.
Also add a comment about hazardous pointer punning in threadRun(),
and avoid using "thread" to refer to the threads array as a whole.
Fabien Coelho and Tom Lane, per suggestion from Alvaro Herrera
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904032126060.7997@lancre M src/bin/pgbench/pgbench.c
Reduce overhead of pg_mcv_list (de)serialization
commit : c50b3158bfd7fc8c2a0b2d2ede4415fd9859acd1
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 3 Apr 2019 21:08:36 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 3 Apr 2019 21:08:36 +0200 Commit ea4e1c0e8f resolved issues with memory alignment in serialized
pg_mcv_list values, but it required copying data to/from the varlena
buffer during serialization and deserialization. As the MCV lits may
be fairly large, the overhead (memory consumption, CPU usage) can get
rather significant too.
This change tweaks the serialization format so that the alignment is
correct with respect to the varlena value, and so the parts may be
accessed directly without copying the data.
Catversion bump, as it affects existing pg_statistic_ext data. M src/backend/statistics/mcv.c
M src/include/catalog/catversion.h
GSSAPI encryption support
commit : b0b39f72b9904bcb80f97b35837ccff1578aa4b8
author : Stephen Frost <sfrost@snowman.net>
date : Wed, 3 Apr 2019 15:02:33 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Wed, 3 Apr 2019 15:02:33 -0400 On both the frontend and backend, prepare for GSSAPI encryption
support by moving common code for error handling into a separate file.
Fix a TODO for handling multiple status messages in the process.
Eliminate the OIDs, which have not been needed for some time.
Add frontend and backend encryption support functions. Keep the
context initiation for authentication-only separate on both the
frontend and backend in order to avoid concerns about changing the
requested flags to include encryption support.
In postmaster, pull GSSAPI authorization checking into a shared
function. Also share the initiator name between the encryption and
non-encryption codepaths.
For HBA, add "hostgssenc" and "hostnogssenc" entries that behave
similarly to their SSL counterparts. "hostgssenc" requires either
"gss", "trust", or "reject" for its authentication.
Similarly, add a "gssencmode" parameter to libpq. Supported values are
"disable", "require", and "prefer". Notably, negotiation will only be
attempted if credentials can be acquired. Move credential acquisition
into its own function to support this behavior.
Add a simple pg_stat_gssapi view similar to pg_stat_ssl, for monitoring
if GSSAPI authentication was used, what principal was used, and if
encryption is being used on the connection.
Finally, add documentation for everything new, and update existing
documentation on connection security.
Thanks to Michael Paquier for the Windows fixes.
Author: Robbie Harwood, with changes to the read/write functions by me.
Reviewed in various forms and at different times by: Michael Paquier,
Andres Freund, David Steele.
Discussion: https://www.postgresql.org/message-id/flat/jlg1tgq1ktm.fsf@thriss.redhat.com M doc/src/sgml/client-auth.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/runtime.sgml
M src/backend/catalog/system_views.sql
M src/backend/libpq/Makefile
M src/backend/libpq/auth.c
A src/backend/libpq/be-gssapi-common.c
A src/backend/libpq/be-gssapi-common.h
A src/backend/libpq/be-secure-gssapi.c
M src/backend/libpq/be-secure.c
M src/backend/libpq/hba.c
M src/backend/postmaster/pgstat.c
M src/backend/postmaster/postmaster.c
M src/backend/utils/adt/pgstatfuncs.c
M src/bin/psql/command.c
M src/include/catalog/pg_proc.dat
M src/include/libpq/hba.h
M src/include/libpq/libpq-be.h
M src/include/libpq/libpq.h
M src/include/libpq/pqcomm.h
M src/include/pgstat.h
M src/interfaces/libpq/Makefile
M src/interfaces/libpq/exports.txt
M src/interfaces/libpq/fe-auth.c
M src/interfaces/libpq/fe-connect.c
A src/interfaces/libpq/fe-gssapi-common.c
A src/interfaces/libpq/fe-gssapi-common.h
A src/interfaces/libpq/fe-secure-gssapi.c
M src/interfaces/libpq/fe-secure.c
M src/interfaces/libpq/libpq-fe.h
M src/interfaces/libpq/libpq-int.h
A src/test/kerberos/t/002_enc.pl
M src/test/regress/expected/rules.out
M src/tools/msvc/Mkvcbuild.pm
Copy name when cloning FKs recurses to partitions
commit : 5f6fc34af5712995026267b9ace79d06b258a0ae
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Apr 2019 15:32:53 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Apr 2019 15:32:53 -0300 We were passing a string owned by a syscache entry, which was released
before recursing. Fix by pstrdup'ing the string.
Per buildfarm member prion. M src/backend/commands/tablecmds.c
Support foreign keys that reference partitioned tables
commit : f56f8f8da6afd8523b4d5284e02a20ed2b33ef8d
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Apr 2019 14:38:20 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Apr 2019 14:38:20 -0300 Previously, while primary keys could be made on partitioned tables, it
was not possible to define foreign keys that reference those primary
keys. Now it is possible to do that.
Author: Álvaro Herrera
Reviewed-by: Amit Langote, Jesper Pedersen
Discussion: https://postgr.es/m/20181102234158.735b3fevta63msbj@alvherre.pgsql M doc/src/sgml/ref/create_table.sgml
M src/backend/commands/tablecmds.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/adt/ruleutils.c
M src/bin/psql/describe.c
M src/include/commands/tablecmds.h
M src/include/commands/trigger.h
M src/include/utils/ruleutils.h
A src/test/isolation/expected/fk-partitioned-1.out
A src/test/isolation/expected/fk-partitioned-2.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/fk-partitioned-1.spec
A src/test/isolation/specs/fk-partitioned-2.spec
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Generate less WAL during GiST, GIN and SP-GiST index build.
commit : 9155580fd5fc2a0cbb23376dfca7cd21f59c2c7b
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 3 Apr 2019 17:03:15 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 3 Apr 2019 17:03:15 +0300 Instead of WAL-logging every modification during the build separately,
first build the index without any WAL-logging, and make a separate pass
through the index at the end, to write all pages to the WAL. This
significantly reduces the amount of WAL generated, and is usually also
faster, despite the extra I/O needed for the extra scan through the index.
WAL generated this way is also faster to replay.
For GiST, the LSN-NSN interlock makes this a little tricky. All pages must
be marked with a valid (i.e. non-zero) LSN, so that the parent-child
LSN-NSN interlock works correctly. We now use magic value 1 for that during
index build. Change the fake LSN counter to begin from 1000, so that 1 is
safely smaller than any real or fake LSN. 2 would've been enough for our
purposes, but let's reserve a bigger range, in case we need more special
values in the future.
Author: Anastasia Lubennikova, Andrey V. Lepikhov
Reviewed-by: Heikki Linnakangas, Dmitry Dolgov M src/backend/access/gin/ginbtree.c
M src/backend/access/gin/gindatapage.c
M src/backend/access/gin/ginentrypage.c
M src/backend/access/gin/gininsert.c
M src/backend/access/gin/ginutil.c
M src/backend/access/gin/ginvacuum.c
M src/backend/access/gin/ginxlog.c
M src/backend/access/gist/gist.c
M src/backend/access/gist/gistbuild.c
M src/backend/access/gist/gistutil.c
M src/backend/access/gist/gistxlog.c
M src/backend/access/rmgrdesc/gindesc.c
M src/backend/access/rmgrdesc/gistdesc.c
M src/backend/access/rmgrdesc/spgdesc.c
M src/backend/access/spgist/spgdoinsert.c
M src/backend/access/spgist/spginsert.c
M src/backend/access/spgist/spgxlog.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xloginsert.c
M src/include/access/gin.h
M src/include/access/ginxlog.h
M src/include/access/gist.h
M src/include/access/gist_private.h
M src/include/access/gistxlog.h
M src/include/access/spgxlog.h
M src/include/access/xlogdefs.h
M src/include/access/xloginsert.h
Correctly initialize newly added struct member
commit : 5f768045a1a25847a3eea59d309e28c8141aed44
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Apr 2019 09:56:20 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 3 Apr 2019 09:56:20 -0300 Valgrind was rightly complaining that IndexVacuumInfo->report_progress
(added by commit ab0dfc961b6a) was not being initialized in some code
paths. Repair.
Per buildfarm member lousyjack. M src/backend/access/heap/vacuumlazy.c
Prevent use of uninitialized variable
commit : e8abf97af770401934a2fc4887940b76403520f0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 2 Apr 2019 16:03:26 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 2 Apr 2019 16:03:26 -0300 Per buildfarm member longfin. M src/backend/storage/lmgr/lmgr.c
Update expected output for modified catalog definition
commit : 11074f26bc072334ab91e5646d113f95f884bd07
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 2 Apr 2019 15:43:32 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 2 Apr 2019 15:43:32 -0300 Pilot error in previous commit M src/test/regress/expected/rules.out
Report progress of CREATE INDEX operations
commit : ab0dfc961b6a821f23d9c40c723d11380ce195a6
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 2 Apr 2019 15:18:08 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 2 Apr 2019 15:18:08 -0300 This uses the progress reporting infrastructure added by c16dc1aca5e0,
adding support for CREATE INDEX and CREATE INDEX CONCURRENTLY.
There are two pieces to this: one is index-AM-agnostic, and the other is
AM-specific. The latter is fairly elaborate for btrees, including
reportage for parallel index builds and the separate phases that btree
index creation uses; other index AMs, which are much simpler in their
building procedures, have simplistic reporting only, but that seems
sufficient, at least for non-concurrent builds.
The index-AM-agnostic part is fairly complete, providing insight into
the CONCURRENTLY wait phases as well as block-based progress during the
index validation table scan. (The index validation index scan requires
patching each AM, which has not been included here.)
Reviewers: Rahila Syed, Pavan Deolasee, Tatsuro Yamada
Discussion: https://postgr.es/m/20181220220022.mg63bhk26zdpvmcj@alvherre.pgsql M contrib/amcheck/verify_nbtree.c
M contrib/bloom/blinsert.c
M contrib/bloom/blutils.c
M doc/src/sgml/indexam.sgml
M doc/src/sgml/monitoring.sgml
M src/backend/access/brin/brin.c
M src/backend/access/gin/gininsert.c
M src/backend/access/gin/ginutil.c
M src/backend/access/gist/gist.c
M src/backend/access/gist/gistbuild.c
M src/backend/access/hash/hash.c
M src/backend/access/hash/hashsort.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/nbtree/nbtree.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/nbtree/nbtutils.c
M src/backend/access/spgist/spginsert.c
M src/backend/access/spgist/spgutils.c
M src/backend/catalog/index.c
M src/backend/catalog/system_views.sql
M src/backend/commands/indexcmds.c
M src/backend/storage/ipc/standby.c
M src/backend/storage/lmgr/lmgr.c
M src/backend/storage/lmgr/lock.c
M src/backend/utils/adt/amutils.c
M src/backend/utils/adt/pgstatfuncs.c
M src/include/access/amapi.h
M src/include/access/genam.h
M src/include/access/nbtree.h
M src/include/access/tableam.h
M src/include/catalog/catversion.h
M src/include/catalog/pg_proc.dat
M src/include/commands/progress.h
M src/include/pgstat.h
M src/include/storage/lmgr.h
M src/include/storage/lock.h
M src/test/regress/expected/rules.out
Add support for partial TOAST decompression
commit : 4d0e994eed83c845a05da6e9a417b4efec67efaf
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 2 Apr 2019 12:35:32 -0400
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 2 Apr 2019 12:35:32 -0400 When asked for a slice of a TOAST entry, decompress enough to return the
slice instead of decompressing the entire object.
For use cases where the slice is at, or near, the beginning of the entry,
this avoids a lot of unnecessary decompression work.
This changes the signature of pglz_decompress() by adding a boolean to
indicate if it's ok for the call to finish before consuming all of the
source or destination buffers.
Author: Paul Ramsey
Reviewed-By: Rafia Sabih, Darafei Praliaskouski, Regina Obe
Discussion: https://postgr.es/m/CACowWR07EDm7Y4m2kbhN_jnys%3DBBf9A6768RyQdKm_%3DNpkcaWg%40mail.gmail.com M src/backend/access/heap/tuptoaster.c
M src/backend/access/transam/xlogreader.c
M src/backend/utils/adt/varlena.c
M src/common/pg_lzcompress.c
M src/include/common/pg_lzcompress.h
postgres_fdw: Perform the (FINAL, NULL) upperrel operations remotely.
commit : d50d172e517c1d2aabff3ceb3ad3113b909c5017
author : Etsuro Fujita <efujita@postgresql.org>
date : Tue, 2 Apr 2019 20:30:45 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Tue, 2 Apr 2019 20:30:45 +0900 The upper-planner pathification allows FDWs to arrange to push down
different types of upper-stage operations to the remote side. This
commit teaches postgres_fdw to do it for the (FINAL, NULL) upperrel,
which is responsible for doing LockRows, LIMIT, and/or ModifyTable.
This provides the ability for postgres_fdw to handle SELECT commands
so that it 1) skips the LockRows step (if any) (note that this is
safe since it performs early locking) and 2) pushes down the LIMIT
and/or OFFSET restrictions (if any) to the remote side. This doesn't
handle the INSERT/UPDATE/DELETE cases.
Author: Etsuro Fujita
Reviewed-By: Antonin Houska and Jeff Janes
Discussion: https://postgr.es/m/87pnz1aby9.fsf@news-spur.riddles.org.uk M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/postgres_fdw.h
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/optimizer/plan/planner.c
M src/include/nodes/pathnodes.h
Refactor create_limit_path() to share cost adjustment code with FDWs.
commit : aef65db6769e3f2c855dd89edcf95a536a9ab74f
author : Etsuro Fujita <efujita@postgresql.org>
date : Tue, 2 Apr 2019 19:55:12 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Tue, 2 Apr 2019 19:55:12 +0900 This is in preparation for an upcoming commit.
Author: Etsuro Fujita
Reviewed-By: Antonin Houska and Jeff Janes
Discussion: https://postgr.es/m/87pnz1aby9.fsf@news-spur.riddles.org.uk M src/backend/optimizer/util/pathnode.c
M src/include/optimizer/pathnode.h
postgres_fdw: Modify regression tests for EPQ-related planning problems.
commit : 0269edefacb78700c95572c41a5a4c8633b631b6
author : Etsuro Fujita <efujita@postgresql.org>
date : Tue, 2 Apr 2019 19:38:56 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Tue, 2 Apr 2019 19:38:56 +0900 This prevents the tests added by commit 4bbf6edfbd and adjusted by
commit 99f6a17dd6 from being useless by plan changes created by an
upcoming commit.
Author: Etsuro Fujita
Discussion: https://postgr.es/m/87pnz1aby9.fsf@news-spur.riddles.org.uk M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
postgres_fdw: Perform the (ORDERED, NULL) upperrel operations remotely.
commit : ffab494a4d4676a71e830b2d7285eeeb5f2b53d7
author : Etsuro Fujita <efujita@postgresql.org>
date : Tue, 2 Apr 2019 19:20:30 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Tue, 2 Apr 2019 19:20:30 +0900 The upper-planner pathification allows FDWs to arrange to push down
different types of upper-stage operations to the remote side. This
commit teaches postgres_fdw to do it for the (ORDERED, NULL) upperrel,
which is responsible for evaluating the query's ORDER BY ordering.
Since postgres_fdw is already able to evaluate that ordering remotely
for foreign baserels and foreign joinrels (see commit aa09cd242f et al.),
this adds support for that for foreign grouping relations.
Author: Etsuro Fujita
Reviewed-By: Antonin Houska and Jeff Janes
Discussion: https://postgr.es/m/87pnz1aby9.fsf@news-spur.riddles.org.uk M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/postgres_fdw.h
Perform RLS subquery checks as the right user when going via a view.
commit : e2d28c0f404713f564dc2250646551c75172f17b
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Tue, 2 Apr 2019 08:13:59 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Tue, 2 Apr 2019 08:13:59 +0100 When accessing a table with RLS via a view, the RLS checks are
performed as the view owner. However, the code neglected to propagate
that to any subqueries in the RLS checks. Fix that by calling
setRuleCheckAsUser() for all RLS policy quals and withCheckOption
checks for RTEs with RLS.
Back-patch to 9.5 where RLS was added.
Per bug #15708 from daurnimator.
Discussion: https://postgr.es/m/15708-d65cab2ce9b1717a@postgresql.org M src/backend/rewrite/rowsecurity.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Add progress reporting to pg_checksums
commit : 280e5f14056bf34a0f52320f659fb93acfda0876
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 2 Apr 2019 10:58:07 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 2 Apr 2019 10:58:07 +0900 This adds a new option to pg_checksums called -P/--progress, showing
every second some information about the computation state of an
operation for --check and --enable (--disable only updates the control
file and is quick). This requires a pre-scan of the data folder so as
the total size of checksummable items can be calculated, and then it
gets compared to the amount processed.
Similarly to what is done for pg_rewind and pg_basebackup, the
information printed in the progress report consists of the current
amount of data computed and the total amount of data to compute. This
could be extended later on.
Author: Michael Banck, Bernd Helmle
Reviewed-by: Fabien Coelho, Michael Paquier
Discussion: https://postgr.es/m/1535719851.1286.17.camel@credativ.de M doc/src/sgml/ref/pg_checksums.sgml
M src/bin/pg_checksums/pg_checksums.c
Add wal_recycle and wal_init_zero GUCs.
commit : 475861b2615dd63ae8431d811749a6f9a15bbfd6
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 2 Apr 2019 14:37:14 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 2 Apr 2019 14:37:14 +1300 On at least ZFS, it can be beneficial to create new WAL files every
time and not to bother zero-filling them. Since it's not clear which
other filesystems might benefit from one or both of those things,
add individual GUCs to control those two behaviors independently and
make only very general statements in the docs.
Author: Jerry Jelinek, with some adjustments by Thomas Munro
Reviewed-by: Alvaro Herrera, Andres Freund, Tomas Vondra, Robert Haas and others
Discussion: https://postgr.es/m/CACPQ5Fo00QR7LNAcd1ZjgoBi4y97%2BK760YABs0vQHH5dLdkkMA%40mail.gmail.com M doc/src/sgml/config.sgml
M src/backend/access/transam/xlog.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
M src/include/access/xlog.h
Only allow heap in a number of contrib modules.
commit : 4b82664156c230b59607704506f5b0a32ef490a2
author : Andres Freund <andres@anarazel.de>
date : Mon, 1 Apr 2019 14:57:21 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 1 Apr 2019 14:57:21 -0700 Contrib modules pgrowlocks, pgstattuple and some functionality in
pageinspect currently only supports the heap table AM. As they are all
concerned with low-level details that aren't reasonably exposed via
tableam, error out if invoked on a non heap relation.
Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M contrib/pageinspect/heapfuncs.c
M contrib/pgrowlocks/pgrowlocks.c
M contrib/pgstattuple/pgstatapprox.c
M contrib/pgstattuple/pgstattuple.c
tableam: Add table_finish_bulk_insert().
commit : d45e40158623baacd3f36f92a670d435cc1e845f
author : Andres Freund <andres@anarazel.de>
date : Mon, 1 Apr 2019 14:41:42 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 1 Apr 2019 14:41:42 -0700 This replaces the previous calls of heap_sync() in places using
bulk-insert. By passing in the flags used for bulk-insert the AM can
decide (first at insert time and then during the finish call) which of
the optimizations apply to it, and what operations are necessary to
finish a bulk insert operation.
Also change HEAP_INSERT_* flags to TABLE_INSERT, and rename hi_options
to ti_options.
These changes are made even in copy.c, which hasn't yet been converted
to tableam. There's no harm in doing so.
Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M src/backend/access/heap/heapam_handler.c
M src/backend/commands/copy.c
M src/backend/commands/createas.c
M src/backend/commands/matview.c
M src/backend/commands/tablecmds.c
M src/include/access/tableam.h
Restrict pgbench’s zipfian parameter to ensure good performance.
commit : 26a76cb64072df6fa5585c2c15df39970ccdce01
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Apr 2019 17:37:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Apr 2019 17:37:26 -0400 Remove the code that supported zipfian distribution parameters less
than 1.0, as it had undocumented performance hazards, and it's not
clear that the case is useful enough to justify either fixing or
documenting those hazards.
Also, since the code path for parameter > 1.0 could perform badly
for values very close to 1.0, establish a minimum allowed value
of 1.001. This solution seems superior to the previous vague
documentation warning about small values not performing well.
Fabien Coelho, per a gripe from Tomas Vondra
Discussion: https://postgr.es/m/b5e172e9-ad22-48a3-86a3-589afa20e8f7@2ndquadrant.com M doc/src/sgml/ref/pgbench.sgml
M src/bin/pgbench/pgbench.c
M src/bin/pgbench/t/001_pgbench_with_server.pl
Fix deadlock in heap_compute_xid_horizon_for_tuples().
commit : 4fd05bb55b40a3c9dde2b19942f275fc31b5225a
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 2 Apr 2019 09:08:15 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 2 Apr 2019 09:08:15 +1300 We can't call code that uses syscache while we hold buffer locks
on a catalog relation. If passed such a relation, just fall back
to the general effective_io_concurrency GUC rather than trying to
look up the containing tablespace's IO concurrency setting.
We might find a better way to control prefetching in follow-up
work, but for now this is enough to avoid the deadlock introduced
by commit 558a9165e0.
Reviewed-by: Andres Freund
Diagnosed-by: Peter Geoghegan
Discussion: https://postgr.es/m/CA%2BhUKGLCwPF0S4Mk7S8qw%2BDK0Bq65LueN9rofAA3HHSYikW-Zw%40mail.gmail.com
Discussion: https://postgr.es/m/962831d8-c18d-180d-75fb-8b842e3a2742%40chrullrich.net M src/backend/access/heap/heapam.c
Improve documentation about our XML functionality.
commit : 12d46ac392d00fa0d103f445aa4997f97029e007
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Apr 2019 16:20:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Apr 2019 16:20:22 -0400 Add a section explaining how our XML features depart from current
versions of the SQL standard. Update and clarify the descriptions
of some XML functions.
Chapman Flack, reviewed by Ryan Lambert
Discussion: https://postgr.es/m/5BD1284C.1010305@anastigmatix.net
Discussion: https://postgr.es/m/5C81F8C0.6090901@anastigmatix.net
Discussion: https://postgr.es/m/CAN-V+g-6JqUQEQZ55Q3toXEN6d5Ez5uvzL4VR+8KtvJKj31taw@mail.gmail.com M doc/src/sgml/datatype.sgml
M doc/src/sgml/features.sgml
M doc/src/sgml/func.sgml
M src/backend/catalog/sql_features.txt
Add volatile qualifier missed in commit 2e616dee9.
commit : b2b819019f4449f2fd889ce0c39ffa81ebfaee16
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Apr 2019 14:37:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Apr 2019 14:37:25 -0400 Noted by Pavel Stehule
Discussion: https://postgr.es/m/CAFj8pRAaGO5FX7bnP3E=mRssoK8y5T78x7jKy-vDiyS68L888Q@mail.gmail.com M src/backend/utils/adt/xml.c
Unified logging system for command-line programs
commit : cc8d41511721d25d557fc02a46c053c0a602fed0
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 1 Apr 2019 14:24:37 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 1 Apr 2019 14:24:37 +0200 This unifies the various ad hoc logging (message printing, error
printing) systems used throughout the command-line programs.
Features:
- Program name is automatically prefixed.
- Message string does not end with newline. This removes a common
source of inconsistencies and omissions.
- Additionally, a final newline is automatically stripped, simplifying
use of PQerrorMessage() etc., another common source of mistakes.
- I converted error message strings to use %m where possible.
- As a result of the above several points, more translatable message
strings can be shared between different components and between
frontends and backend, without gratuitous punctuation or whitespace
differences.
- There is support for setting a "log level". This is not meant to be
user-facing, but can be used internally to implement debug or
verbose modes.
- Lazy argument evaluation, so no significant overhead if logging at
some level is disabled.
- Some color in the messages, similar to gcc and clang. Set
PG_COLOR=auto to try it out. Some colors are predefined, but can be
customized by setting PG_COLORS.
- Common files (common/, fe_utils/, etc.) can handle logging much more
simply by just using one API without worrying too much about the
context of the calling program, requiring callbacks, or having to
pass "progname" around everywhere.
- Some programs called setvbuf() to make sure that stderr is
unbuffered, even on Windows. But not all programs did that. This
is now done centrally.
Soft goals:
- Reduces vertical space use and visual complexity of error reporting
in the source code.
- Encourages more deliberate classification of messages. For example,
in some cases it wasn't clear without analyzing the surrounding code
whether a message was meant as an error or just an info.
- Concepts and terms are vaguely aligned with popular logging
frameworks such as log4j and Python logging.
This is all just about printing stuff out. Nothing affects program
flow (e.g., fatal exits). The uses are just too varied to do that.
Some existing code had wrappers that do some kind of print-and-exit,
and I adapted those.
I tried to keep the output mostly the same, but there is a lot of
historical baggage to unwind and special cases to consider, and I
might not always have succeeded. One significant change is that
pg_rewind used to write all error messages to stdout. That is now
changed to stderr.
Reviewed-by: Donald Dong <xdong@csumb.edu>
Reviewed-by: Arthur Zakirov <a.zakirov@postgrespro.ru>
Discussion: https://www.postgresql.org/message-id/flat/6a609b43-4f57-7348-6480-bd022f924310@2ndquadrant.com M doc/src/sgml/ref/clusterdb.sgml
M doc/src/sgml/ref/createdb.sgml
M doc/src/sgml/ref/createuser.sgml
M doc/src/sgml/ref/dropdb.sgml
M doc/src/sgml/ref/dropuser.sgml
M doc/src/sgml/ref/initdb.sgml
M doc/src/sgml/ref/pg_basebackup.sgml
M doc/src/sgml/ref/pg_checksums.sgml
M doc/src/sgml/ref/pg_controldata.sgml
M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_dumpall.sgml
M doc/src/sgml/ref/pg_isready.sgml
M doc/src/sgml/ref/pg_receivewal.sgml
M doc/src/sgml/ref/pg_recvlogical.sgml
M doc/src/sgml/ref/pg_resetwal.sgml
M doc/src/sgml/ref/pg_restore.sgml
M doc/src/sgml/ref/pg_rewind.sgml
M doc/src/sgml/ref/pg_waldump.sgml
M doc/src/sgml/ref/psql-ref.sgml
M doc/src/sgml/ref/reindexdb.sgml
M doc/src/sgml/ref/vacuumdb.sgml
M src/backend/access/transam/xlog.c
M src/backend/utils/misc/pg_controldata.c
M src/bin/initdb/initdb.c
M src/bin/initdb/nls.mk
M src/bin/pg_archivecleanup/Makefile
M src/bin/pg_archivecleanup/nls.mk
M src/bin/pg_archivecleanup/pg_archivecleanup.c
M src/bin/pg_basebackup/nls.mk
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/pg_recvlogical.c
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/streamutil.c
M src/bin/pg_basebackup/walmethods.c
M src/bin/pg_checksums/Makefile
M src/bin/pg_checksums/nls.mk
M src/bin/pg_checksums/pg_checksums.c
M src/bin/pg_controldata/Makefile
M src/bin/pg_controldata/pg_controldata.c
M src/bin/pg_ctl/Makefile
M src/bin/pg_ctl/pg_ctl.c
M src/bin/pg_dump/common.c
M src/bin/pg_dump/compress_io.c
M src/bin/pg_dump/nls.mk
M src/bin/pg_dump/parallel.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_archiver.h
M src/bin/pg_dump/pg_backup_custom.c
M src/bin/pg_dump/pg_backup_db.c
M src/bin/pg_dump/pg_backup_directory.c
M src/bin/pg_dump/pg_backup_null.c
M src/bin/pg_dump/pg_backup_tar.c
M src/bin/pg_dump/pg_backup_utils.c
M src/bin/pg_dump/pg_backup_utils.h
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/pg_dump_sort.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_dump/pg_restore.c
M src/bin/pg_dump/t/001_basic.pl
M src/bin/pg_dump/t/002_pg_dump.pl
M src/bin/pg_resetwal/Makefile
M src/bin/pg_resetwal/nls.mk
M src/bin/pg_resetwal/pg_resetwal.c
M src/bin/pg_resetwal/t/002_corrupted.pl
M src/bin/pg_rewind/Makefile
M src/bin/pg_rewind/copy_fetch.c
M src/bin/pg_rewind/datapagemap.c
M src/bin/pg_rewind/file_ops.c
M src/bin/pg_rewind/filemap.c
M src/bin/pg_rewind/libpq_fetch.c
M src/bin/pg_rewind/logging.c
M src/bin/pg_rewind/logging.h
M src/bin/pg_rewind/nls.mk
M src/bin/pg_rewind/parsexlog.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pg_rewind/pg_rewind.h
M src/bin/pg_rewind/timeline.c
M src/bin/pg_test_fsync/Makefile
M src/bin/pg_test_fsync/pg_test_fsync.c
M src/bin/pg_upgrade/pg_upgrade.c
M src/bin/pg_waldump/Makefile
M src/bin/pg_waldump/nls.mk
M src/bin/pg_waldump/pg_waldump.c
M src/bin/pgbench/pgbench.c
M src/bin/psql/command.c
M src/bin/psql/common.c
M src/bin/psql/common.h
M src/bin/psql/copy.c
M src/bin/psql/crosstabview.c
M src/bin/psql/describe.c
M src/bin/psql/help.c
M src/bin/psql/input.c
M src/bin/psql/large_obj.c
M src/bin/psql/mainloop.c
M src/bin/psql/nls.mk
M src/bin/psql/psqlscanslash.l
M src/bin/psql/startup.c
M src/bin/psql/tab-complete.c
M src/bin/psql/variables.c
M src/bin/psql/variables.h
M src/bin/scripts/clusterdb.c
M src/bin/scripts/common.c
M src/bin/scripts/createdb.c
M src/bin/scripts/createuser.c
M src/bin/scripts/dropdb.c
M src/bin/scripts/dropuser.c
M src/bin/scripts/nls.mk
M src/bin/scripts/pg_isready.c
M src/bin/scripts/reindexdb.c
M src/bin/scripts/vacuumdb.c
M src/common/controldata_utils.c
M src/common/file_utils.c
M src/common/pgfnames.c
M src/common/restricted_token.c
M src/common/rmtree.c
M src/fe_utils/Makefile
A src/fe_utils/logging.c
M src/fe_utils/psqlscan.l
M src/include/common/controldata_utils.h
M src/include/common/file_utils.h
M src/include/common/restricted_token.h
A src/include/fe_utils/logging.h
M src/include/fe_utils/psqlscan.h
M src/interfaces/ecpg/test/Makefile
M src/nls-global.mk
M src/test/isolation/Makefile
M src/test/perl/TestLib.pm
M src/test/regress/GNUmakefile
M src/test/regress/pg_regress.c
M src/tools/msvc/Mkvcbuild.pm
Throw error in jsonb_path_match() when result is not single boolean
commit : b4cc19ab01ffe6a72a915b21aa41536de80923f5
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 1 Apr 2019 18:09:20 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 1 Apr 2019 18:09:20 +0300 jsonb_path_match() checks if jsonb document matches jsonpath query. Therefore,
jsonpath query should return single boolean. Currently, if result of jsonpath
is not a single boolean, NULL is returned independently whether silent mode
is on or off. But that appears to be wrong when silent mode is off. This
commit makes jsonb_path_match() throw an error in this case.
Author: Nikita Glukhov M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/sql/jsonb_jsonpath.sql
Restrict some cases in parsing numerics in jsonpath
commit : 2e643501e5281ad5e0fa626dab1d51c1d38f639a
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 1 Apr 2019 18:09:09 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 1 Apr 2019 18:09:09 +0300 Jsonpath now accepts integers with leading zeroes and floats starting with
a dot. However, SQL standard requires to follow JSON specification, which
doesn't allow none of these cases. Our json[b] datatypes also restrict that.
So, restrict it in jsonpath altogether.
Author: Nikita Glukhov M src/backend/utils/adt/jsonpath_scan.l
M src/test/regress/expected/jsonpath.out
GIN support for @@ and @? jsonpath operators
commit : 0a02e2ae0236103e641f6570b8135b7ee8a83686
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 1 Apr 2019 18:08:15 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 1 Apr 2019 18:08:15 +0300 This commit makes existing GIN operator classes jsonb_ops and json_path_ops
support "jsonb @@ jsonpath" and "jsonb @? jsonpath" operators. Basic idea is
to extract statements of following form out of jsonpath.
key1.key2. ... .keyN = const
The rest of jsonpath is rechecked from heap.
Catversion is bumped.
Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com
Author: Nikita Glukhov, Alexander Korotkov
Reviewed-by: Jonathan Katz, Pavel Stehule M doc/src/sgml/gin.sgml
M doc/src/sgml/json.sgml
M src/backend/utils/adt/jsonb_gin.c
M src/include/catalog/catversion.h
M src/include/catalog/pg_amop.dat
M src/include/utils/jsonb.h
M src/include/utils/jsonpath.h
M src/test/regress/expected/jsonb.out
M src/test/regress/expected/opr_sanity.out
M src/test/regress/sql/jsonb.sql
M src/tools/pgindent/typedefs.list
Catch syntax error in generated column definition
commit : 7241911782a7420e38b6e50b57d304ea48bc5362
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 1 Apr 2019 10:46:37 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 1 Apr 2019 10:46:37 +0200 The syntax
GENERATED BY DEFAULT AS (expr)
is not allowed but we have to accept it in the grammar to avoid
shift/reduce conflicts because of the similar syntax for identity
columns. The existing code just ignored this, incorrectly. Add an
explicit error check and a bespoke error message.
Reported-by: Justin Pryzby <pryzby@telsasoft.com> M src/backend/parser/gram.y
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql
Fix thinko in allocation call during MVC list deserialization
commit : 4ae7f02b0364ccba49a82efbfff46125fb357d6c
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 1 Apr 2019 14:16:27 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 1 Apr 2019 14:16:27 +0900 Spotted by Coverity. M src/backend/statistics/mcv.c
Update HINT for pre-existing shared memory block.
commit : 5a907404b52753c4d6c6a7c21765aeaa42fd6a3b
author : Noah Misch <noah@leadboat.com>
date : Sun, 31 Mar 2019 19:32:48 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 31 Mar 2019 19:32:48 -0700 One should almost always terminate an old process, not use a manual
removal tool like ipcrm. Removal of the ipcclean script eleven years
ago (39627b1ae680cba44f6e56ca5facec4fdbfe9495) and its non-replacement
corroborate that manual shm removal is now a niche goal. Back-patch to
9.4 (all supported versions).
Reviewed by Daniel Gustafsson and Kyotaro HORIGUCHI.
Discussion: https://postgr.es/m/20180812064815.GB2301738@rfd.leadboat.com M src/backend/utils/init/miscinit.c
tableam: bitmap table scan.
commit : bfbcad478f05794e5e7ea1339e62a1d258c99b6c
author : Andres Freund <andres@anarazel.de>
date : Sun, 31 Mar 2019 17:51:49 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 31 Mar 2019 17:51:49 -0700 This moves bitmap heap scan support to below an optional tableam
callback. It's optional as the whole concept of bitmap heapscans is
fairly block specific.
This basically moves the work previously done in bitgetpage() into the
new scan_bitmap_next_block callback, and the direct poking into the
buffer done in BitmapHeapNext() into the new scan_bitmap_next_tuple()
callback.
The abstraction is currently somewhat leaky because
nodeBitmapHeapscan.c's prefetching and visibilitymap based logic
remains - it's likely that we'll later have to move more into the
AM. But it's not trivial to do so without introducing a significant
amount of code duplication between the AMs, so that's a project for
later.
Note that now nodeBitmapHeapscan.c and the associated node types are a
bit misnamed. But it's not clear whether renaming wouldn't be a cure
worse than the disease. Either way, that'd be best done in a separate
commit.
Author: Andres Freund
Reviewed-By: Robert Haas (in an older version)
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M src/backend/access/heap/heapam_handler.c
M src/backend/access/table/tableamapi.c
M src/backend/executor/nodeBitmapHeapscan.c
M src/backend/optimizer/util/plancat.c
M src/include/access/tableam.h
M src/include/nodes/execnodes.h
M src/include/nodes/tidbitmap.h
tableam: sample scan.
commit : 73c954d24896aeb05de0f81d75e891a858e439e9
author : Andres Freund <andres@anarazel.de>
date : Sat, 30 Mar 2019 20:18:53 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sat, 30 Mar 2019 20:18:53 -0700 This moves sample scan support to below tableam. It's not optional as
there is, in contrast to e.g. bitmap heap scans, no alternative way to
perform tablesample queries. If an AM can't deal with the block based
API, it will have to throw an ERROR.
The tableam callbacks for this are block based, but given the current
TsmRoutine interface, that seems to be required.
The new interface doesn't require TsmRoutines to perform visibility
checks anymore - that requires the TsmRoutine to know details about
the AM, which we want to avoid. To continue to allow taking the
returned number of tuples account SampleScanState now has a donetuples
field (which previously e.g. existed in SystemRowsSamplerData), which
is only incremented after the visibility check succeeds.
Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M contrib/tsm_system_rows/tsm_system_rows.c
M contrib/tsm_system_time/tsm_system_time.c
M doc/src/sgml/tablesample-method.sgml
M src/backend/access/heap/heapam_handler.c
M src/backend/access/table/tableamapi.c
M src/backend/access/tablesample/system.c
M src/backend/executor/nodeSamplescan.c
M src/include/access/tableam.h
M src/include/access/tsmapi.h
M src/include/nodes/execnodes.h
tableam: Formatting and other minor cleanups.
commit : 4bb50236eb561f4639e75a393a5a1c9b8681acfb
author : Andres Freund <andres@anarazel.de>
date : Sat, 30 Mar 2019 20:13:56 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sat, 30 Mar 2019 20:13:56 -0700 The superflous heapam_xlog.h includes were reported by Peter
Geoghegan. M src/backend/access/hash/hash_xlog.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/nbtree/nbtxlog.c
M src/backend/access/table/tableam.c
M src/backend/access/table/tableamapi.c
M src/backend/optimizer/util/plancat.c
M src/include/access/tableam.h
Fix nbtree high key “continuescan” row compare bug.
commit : 76a39f2295ecb040f2ea052320941e1eb9b526c0
author : Peter Geoghegan <pg@bowt.ie>
date : Sun, 31 Mar 2019 17:24:04 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Sun, 31 Mar 2019 17:24:04 -0700 Commit 29b64d1d mishandled skipping over truncated high key attributes
during row comparisons. The row comparison key matching loop would loop
forever when a truncated attribute was encountered for a row compare
subkey. Fix by following the example of other code in the loop: advance
the current subkey, or break out of the loop when the last subkey is
reached.
Add test coverage for the relevant _bt_check_rowcompare() code path.
The new test case is somewhat tied to nbtree implementation details,
which isn't ideal, but seems unavoidable. M src/backend/access/nbtree/nbtutils.c
M src/test/regress/expected/index_including.out
M src/test/regress/sql/index_including.sql
Add test case exercising formerly-unreached code in inheritance_planner.
commit : 8fba397f0ca7b9a1fd59ab2b676c057dde4f8219
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 31 Mar 2019 15:49:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 31 Mar 2019 15:49:06 -0400 There was some debate about whether the code I'd added to remap
AppendRelInfos obtained from the initial SELECT planning run is
actually necessary. Add a test case demonstrating that it is.
Discussion: https://postgr.es/m/23831.1553873385@sss.pgh.pa.us M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Compute root->qual_security_level in a less random place.
commit : 9fd4de119c609b4110eea74f00f7b9002e14aa38
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 31 Mar 2019 13:47:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 31 Mar 2019 13:47:41 -0400 We can set this up once and for all in subquery_planner's initial survey
of the flattened rangetable, rather than incrementally adjusting it in
build_simple_rel. The previous approach made it rather hard to reason
about exactly when the value would be available, and we were definitely
using it in some places before the final value was computed.
Noted while fooling around with Amit Langote's patch to delay creation
of inheritance child rels. That didn't break this code, but it made it
even more fragile, IMO. M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/util/relnode.c
Skip redundant anti-wraparound vacuums
commit : 2aa6e331ead7f3ad080561495ad4bd3bc7cd8913
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 31 Mar 2019 22:59:12 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 31 Mar 2019 22:59:12 +0900 An anti-wraparound vacuum has to be by definition aggressive as it needs
to work on all the pages of a relation. However it can happen that due
to some concurrent activity an anti-wraparound vacuum is marked as
non-aggressive, which makes it redundant with a previous run, and
it is actually useless as an anti-wraparound vacuum should process all
the pages of a relation. This commit makes such vacuums to be skipped.
An anti-wraparound vacuum not aggressive can be found easily by mixing
low values of autovacuum_freeze_max_age (to control anti-wraparound) and
autovacuum_freeze_table_age (to control the aggressiveness).
28a8fa9 has added some extra logging printing all the possible
combinations of anti-wraparound and aggressive vacuums, which now gets
simplified as an anti-wraparound vacuum also non-aggressive gets
skipped.
Per discussion mainly between Andrew Dunstan, Robert Haas, Álvaro
Herrera, Kyotaro Horiguchi, Masahiko Sawada, and myself.
Author: Kyotaro Horiguchi, Michael Paquier
Reviewed-by: Andrew Dunstan, Álvaro Herrera
Discussion: https://postgr.es/m/20180914153554.562muwr3uwujno75@alvherre.pgsql M src/backend/access/heap/vacuumlazy.c
Have pg_upgrade’s Makefile honor NO_TEMP_INSTALL
commit : 47b3c26642e6850e8dfa7afe01db78320b11549e
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 31 Mar 2019 08:08:14 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 31 Mar 2019 08:08:14 -0400 Backpatch to 9.5, when pg_upgrade's location changed.
Discussion: https://postgr.es/m/5506b8fa-7dad-8483-053c-7ca7ef04f01a@2ndQuadrant.com M src/bin/pg_upgrade/Makefile
tableam: Move heap specific logic from estimate_rel_size below tableam.
commit : 696d78469f3714a8159f7a145af1fe9179fe3291
author : Andres Freund <andres@anarazel.de>
date : Sat, 30 Mar 2019 16:40:33 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sat, 30 Mar 2019 16:40:33 -0700 This just moves the table/matview[/toast] determination of relation
size to a callback, and uses a copy of the existing logic to implement
that callback for heap.
It probably would make sense to also move the index specific logic
into a callback, so the metapage handling (and probably more) can be
index specific. But that's a separate task.
Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M src/backend/access/heap/heapam_handler.c
M src/backend/optimizer/util/plancat.c
M src/include/access/tableam.h
M src/include/optimizer/plancat.h
tableam: VACUUM and ANALYZE support.
commit : 737a292b5de296615a715ddce2b2d83d1ee245c5
author : Andres Freund <andres@anarazel.de>
date : Sat, 30 Mar 2019 16:21:09 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sat, 30 Mar 2019 16:21:09 -0700 This is a relatively straightforward move of the current
implementation to sit below tableam. As the current analyze sampling
implementation is pretty inherently block based, the tableam analyze
interface is as well. It might make sense to generalize that at some
point, but that seems like a larger project that shouldn't be
undertaken at the same time as the introduction of tableam.
Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M src/backend/access/heap/heapam_handler.c
M src/backend/commands/analyze.c
M src/backend/commands/vacuum.c
M src/include/access/tableam.h
Fix typo
commit : 0f5493fdf19306314e7a729750a83b26a3264412
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 31 Mar 2019 03:29:58 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 31 Mar 2019 03:29:58 +0200 Author: John Naylor M src/backend/statistics/mcv.c
Speed up planning when partitions can be pruned at plan time.
commit : 428b260f87e8861ba8e58807b69d433db491c4f4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 30 Mar 2019 18:58:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 30 Mar 2019 18:58:55 -0400 Previously, the planner created RangeTblEntry and RelOptInfo structs
for every partition of a partitioned table, even though many of them
might later be deemed uninteresting thanks to partition pruning logic.
This incurred significant overhead when there are many partitions.
Arrange to postpone creation of these data structures until after
we've processed the query enough to identify restriction quals for
the partitioned table, and then apply partition pruning before not
after creation of each partition's data structures. In this way
we need not open the partition relations at all for partitions that
the planner has no real interest in.
For queries that can be proven at plan time to access only a small
number of partitions, this patch improves the practical maximum
number of partitions from under 100 to perhaps a few thousand.
Amit Langote, reviewed at various times by Dilip Kumar, Jesper Pedersen,
Yoshikazu Imai, and David Rowley
Discussion: https://postgr.es/m/9d7c5112-cb99-6a47-d3be-cf1ee6862a1d@lab.ntt.co.jp M contrib/postgres_fdw/expected/postgres_fdw.out
M src/backend/executor/execPartition.c
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/plan/initsplan.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/prep/preptlist.c
M src/backend/optimizer/util/inherit.c
M src/backend/optimizer/util/plancat.c
M src/backend/optimizer/util/relnode.c
M src/backend/partitioning/partprune.c
M src/include/nodes/plannodes.h
M src/include/optimizer/inherit.h
M src/include/optimizer/pathnode.h
M src/test/regress/expected/partition_aggregate.out
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
Fix compiler warnings in multivariate MCV code
commit : ad3107b97324e0c8cf65932294115b6af9db8ded
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 30 Mar 2019 18:43:16 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 30 Mar 2019 18:43:16 +0100 Compiler warnings were observed on gcc 3.4.6 (on gaur).
The assert is unnecessary, as the indexes are uint16 and so always >= 0.
Reported-by: Tom Lane M src/backend/statistics/mcv.c
Additional fixes of memory alignment in pg_mcv_list code
commit : ea4e1c0e8f583f99c8caab5bcdfbbbaaed0685c0
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 30 Mar 2019 18:34:59 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 30 Mar 2019 18:34:59 +0100 Commit d85e0f366a tried to fix memory alignment issues in serialization
and deserialization of pg_mcv_list values, but it was a few bricks shy.
The arrays of uint16 indexes in serialized items was not aligned, and
the both the values and isnull flags were using the same pointer.
Per investigation by Tom Lane on gaur. M src/backend/statistics/mcv.c
Avoid crash in partitionwise join planning under GEQO.
commit : 7ad6498fd5a654de6e743814c36cf619a3b5ddb6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 30 Mar 2019 12:48:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 30 Mar 2019 12:48:19 -0400 While trying to plan a partitionwise join, we may be faced with cases
where one or both input partitions for a particular segment of the join
have been pruned away. In HEAD and v11, this is problematic because
earlier processing didn't bother to make a pruned RelOptInfo fully
valid. With an upcoming patch to make partition pruning more efficient,
this'll be even more problematic because said RelOptInfo won't exist at
all.
The existing code attempts to deal with this by retroactively making the
RelOptInfo fully valid, but that causes crashes under GEQO because join
planning is done in a short-lived memory context. In v11 we could
probably have fixed this by switching to the planner's main context
while fixing up the RelOptInfo, but that idea doesn't scale well to the
upcoming patch. It would be better not to mess with the base-relation
data structures during join planning, anyway --- that's just a recipe
for order-of-operations bugs.
In many cases, though, we don't actually need the child RelOptInfo,
because if the input is certainly empty then the join segment's result
is certainly empty, so we can skip making a join plan altogether. (The
existing code ultimately arrives at the same conclusion, but only after
doing a lot more work.) This approach works except when the pruned-away
partition is on the nullable side of a LEFT, ANTI, or FULL join, and the
other side isn't pruned. But in those cases the existing code leaves a
lot to be desired anyway --- the correct output is just the result of
the unpruned side of the join, but we were emitting a useless outer join
against a dummy Result. Pending somebody writing code to handle that
more nicely, let's just abandon the partitionwise-join optimization in
such cases.
When the modified code skips making a join plan, it doesn't make a
join RelOptInfo either; this requires some upper-level code to
cope with nulls in part_rels[] arrays. We would have had to have
that anyway after the upcoming patch.
Back-patch to v11 since the crash is demonstrable there.
Discussion: https://postgr.es/m/8305.1553884377@sss.pgh.pa.us M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/partition_aggregate.out
M src/test/regress/expected/partition_join.out
M src/test/regress/sql/partition_aggregate.sql
M src/test/regress/sql/partition_join.sql
doc: Fix typo
commit : ef6576f5379edfa29bb4f99880b0f76dd315dd14
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 30 Mar 2019 17:25:13 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 30 Mar 2019 17:25:13 +0100 Author: Justin Pryzby <pryzby@telsasoft.com> M doc/src/sgml/ref/create_table.sgml
Generated columns
commit : fc22b6623b6b3bab3cb057ccd282c2bfad1a0b30
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 30 Mar 2019 08:13:09 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 30 Mar 2019 08:13:09 +0100 This is an SQL-standard feature that allows creating columns that are
computed from expressions rather than assigned, similar to a view or
materialized view but on a column basis.
This implements one kind of generated column: stored (computed on
write). Another kind, virtual (computed on read), is planned for the
future, and some room is left for it.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/ddl.sgml
M doc/src/sgml/information_schema.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/ref/copy.sgml
M doc/src/sgml/ref/create_foreign_table.sgml
M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/ref/create_trigger.sgml
M doc/src/sgml/textsearch.sgml
M doc/src/sgml/trigger.sgml
M src/backend/access/common/tupdesc.c
M src/backend/catalog/heap.c
M src/backend/catalog/information_schema.sql
M src/backend/commands/copy.c
M src/backend/commands/tablecmds.c
M src/backend/commands/trigger.c
M src/backend/commands/typecmds.c
M src/backend/executor/execMain.c
M src/backend/executor/execReplication.c
M src/backend/executor/nodeModifyTable.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/util/inherit.c
M src/backend/optimizer/util/plancat.c
M src/backend/parser/analyze.c
M src/backend/parser/gram.y
M src/backend/parser/parse_agg.c
M src/backend/parser/parse_expr.c
M src/backend/parser/parse_func.c
M src/backend/parser/parse_relation.c
M src/backend/parser/parse_utilcmd.c
M src/backend/replication/logical/proto.c
M src/backend/replication/logical/relation.c
M src/backend/replication/logical/tablesync.c
M src/backend/replication/logical/worker.c
M src/backend/replication/pgoutput/pgoutput.c
M src/backend/rewrite/rewriteHandler.c
M src/backend/utils/cache/lsyscache.c
M src/backend/utils/cache/partcache.c
M src/backend/utils/cache/relcache.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/pg_dump_sort.c
M src/bin/pg_dump/t/002_pg_dump.pl
M src/bin/psql/describe.c
M src/include/access/tupdesc.h
M src/include/catalog/catversion.h
M src/include/catalog/heap.h
M src/include/catalog/pg_attribute.h
M src/include/catalog/pg_class.dat
M src/include/executor/nodeModifyTable.h
M src/include/nodes/execnodes.h
M src/include/nodes/parsenodes.h
M src/include/optimizer/plancat.h
M src/include/parser/kwlist.h
M src/include/parser/parse_node.h
M src/include/utils/lsyscache.h
M src/pl/plperl/expected/plperl_trigger.out
M src/pl/plperl/plperl.c
M src/pl/plperl/sql/plperl_trigger.sql
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpython/expected/plpython_trigger.out
M src/pl/plpython/plpy_cursorobject.c
M src/pl/plpython/plpy_exec.c
M src/pl/plpython/plpy_spi.c
M src/pl/plpython/plpy_typeio.c
M src/pl/plpython/plpy_typeio.h
M src/pl/plpython/sql/plpython_trigger.sql
M src/pl/tcl/expected/pltcl_trigger.out
M src/pl/tcl/pltcl.c
M src/pl/tcl/sql/pltcl_trigger.sql
M src/test/regress/expected/create_table_like.out
A src/test/regress/expected/generated.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/create_table_like.sql
A src/test/regress/sql/generated.sql
A src/test/subscription/t/011_generated.pl
Small code simplification for REINDEX CONCURRENTLY
commit : 6b8b5364ddd0e4d882562615c6b6c28638ade9f2
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 30 Mar 2019 07:16:24 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 30 Mar 2019 07:16:24 +0100 This was left over from an earlier code structure. M src/backend/commands/indexcmds.c
doc: Small documentation review for REINDEX CONCURRENTLY
commit : 173268f4d011fcae1f909c811e264baf6c838e7a
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 29 Mar 2019 22:47:33 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 29 Mar 2019 22:47:33 +0100 Author: Justin Pryzby <pryzbyj@telsasoft.com> M doc/src/sgml/ref/reindex.sgml
doc: Fix typo
commit : 0267629e1889b3e1e2e6b2f1b41e8993eff86a9b
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 29 Mar 2019 22:41:19 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 29 Mar 2019 22:41:19 +0100 Author: Bossart, Nathan <bossartn@amazon.com> M doc/src/sgml/ref/reindex.sgml
Tweak some nbtree-related code comments.
commit : 9c7fb7e6d8d0fdcabbdc32daad2159812e538bd5
author : Peter Geoghegan <pg@bowt.ie>
date : Fri, 29 Mar 2019 12:29:05 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Fri, 29 Mar 2019 12:29:05 -0700 M contrib/amcheck/verify_nbtree.c
M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtsort.c
M src/include/access/nbtree.h
Fix memory alignment in pg_mcv_list serialization
commit : d85e0f366a347633f255b8d1031ab34733c5e147
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 29 Mar 2019 18:50:51 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 29 Mar 2019 18:50:51 +0100 Blind attempt at fixing ia64, hppa an sparc builds.
The serialized representation of MCV lists did not enforce proper memory
alignment for internal fields, resulting in deserialization issues on
platforms that are more sensitive to this (ia64, sparc and hppa).
This forces a catalog version bump, because the layout of serialized
pg_mcv_list changes.
Broken since 7300a699. M src/backend/statistics/mcv.c
M src/include/catalog/catversion.h
Show table access methods as such in psql’s \dA.
commit : d3a5fc17ebdbeaec81bec1f41e304485b3292da3
author : Andres Freund <andres@anarazel.de>
date : Fri, 29 Mar 2019 08:59:40 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 29 Mar 2019 08:59:40 -0700 Previously we didn't display a type for table access methods.
Author: Haribabu Kommi
Discussion: CAJrrPGeeYOqP3hkZyohDx_8dot4zvPuPMDBmhJ=iC85cTBNeYw@mail.gmail.com M src/bin/psql/describe.c
tableam: Comment fixes.
commit : ffa8444ce4828108e49d961cfa64e31078d978f0
author : Andres Freund <andres@anarazel.de>
date : Fri, 29 Mar 2019 08:16:35 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 29 Mar 2019 08:16:35 -0700 Author: Haribabu Kommi
Discussion: CAJrrPGeeYOqP3hkZyohDx_8dot4zvPuPMDBmhJ=iC85cTBNeYw@mail.gmail.com M src/backend/access/heap/heapam_handler.c
M src/include/access/tableam.h
Reorganize Notes section in documentation of pg_checksums
commit : a7cc52370b2b8a0f9883e299cb07f56d702b58c2
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 29 Mar 2019 23:00:51 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 29 Mar 2019 23:00:51 +0900 This commit reorders the paragraphs of the Notes section in order of
importance, and clarifies better the safe uses of pg_checksums for
replication setups.
Author: Fabien Coelho
Discussion: https://postgr.es/m/alpine.DEB.2.21.1903231404280.18811@lancre M doc/src/sgml/ref/pg_checksums.sgml
doc: Refine README.links further
commit : c0a2ff474a47216031d1835f5878fa4f445f44fe
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 29 Mar 2019 13:36:24 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 29 Mar 2019 13:36:24 +0100 suggested by Chapman Flack <chap@anastigmatix.net> M doc/src/sgml/README.links
Allow existing VACUUM options to take a Boolean argument.
commit : 41b54ba78e8c4d64679ba4daf82e4e2efefe1922
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 29 Mar 2019 08:22:49 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 29 Mar 2019 08:22:49 -0400 This makes VACUUM work more like EXPLAIN already does without changing
the meaning of any commands that already work. It is intended to
facilitate the addition of future VACUUM options that may take
non-Boolean parameters or that default to false.
Masahiko Sawada, reviewed by me.
Discussion: http://postgr.es/m/CA+TgmobpYrXr5sUaEe_T0boabV0DSm=utSOZzwCUNqfLEEm8Mw@mail.gmail.com
Discussion: http://postgr.es/m/CAD21AoBaFcKBAeL5_++j+Vzir2vBBcF4juW7qH8b3HsQY=Q6+w@mail.gmail.com M doc/src/sgml/ref/vacuum.sgml
M src/backend/commands/vacuum.c
M src/backend/parser/gram.y
M src/bin/psql/tab-complete.c
Warn more strongly about the dangers of exclusive backup mode.
commit : c900c15269f0f900d666bd1b0c6df3eff5098678
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 29 Mar 2019 08:09:39 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 29 Mar 2019 08:09:39 -0400 Especially, warn about the hazards of mishandling the backup_label
file. Adjust a couple of server messages to be more clear about
the hazards associated with removing backup_label files, too.
David Steele and Robert Haas, reviewed by Laurenz Albe, Martín
Marqués, Peter Eisentraut, and Magnus Hagander.
Discussion: http://postgr.es/m/7d85c387-000e-16f0-e00b-50bf83c22127@pgmasters.net M doc/src/sgml/backup.sgml
M src/backend/access/transam/xlog.c
Fix incorrect code in new REINDEX CONCURRENTLY code
commit : bb76134b08aa46cdeb0ff1e6d7b392d315529a8c
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 29 Mar 2019 10:53:40 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 29 Mar 2019 10:53:40 +0100 The previous code was adding pointers to transient variables to a
list, but by the time the list was read, the variable might be gone,
depending on the compiler. Fix it by making copies in the proper
memory context. M src/backend/commands/indexcmds.c
REINDEX CONCURRENTLY
commit : 5dc92b844e680c54a7ecd68de0ba53c949c3d605
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 29 Mar 2019 08:25:20 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 29 Mar 2019 08:25:20 +0100 This adds the CONCURRENTLY option to the REINDEX command. A REINDEX
CONCURRENTLY on a specific index creates a new index (like CREATE
INDEX CONCURRENTLY), then renames the old index away and the new index
in place and adjusts the dependencies, and then drops the old
index (like DROP INDEX CONCURRENTLY). The REINDEX command also has
the capability to run its other variants (TABLE, DATABASE) with the
CONCURRENTLY option (but not SYSTEM).
The reindexdb command gets the --concurrently option.
Author: Michael Paquier, Andreas Karlsson, Peter Eisentraut
Reviewed-by: Andres Freund, Fujii Masao, Jim Nasby, Sergei Kornilov
Discussion: https://www.postgresql.org/message-id/flat/60052986-956b-4478-45ed-8bd119e9b9cf%402ndquadrant.com#74948a1044c56c5e817a5050f554ddee M doc/src/sgml/mvcc.sgml
M doc/src/sgml/ref/create_index.sgml
M doc/src/sgml/ref/reindex.sgml
M doc/src/sgml/ref/reindexdb.sgml
M src/backend/catalog/dependency.c
M src/backend/catalog/index.c
M src/backend/catalog/pg_depend.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/parser/gram.y
M src/backend/tcop/utility.c
M src/bin/psql/common.c
M src/bin/psql/tab-complete.c
M src/bin/scripts/reindexdb.c
M src/bin/scripts/t/090_reindexdb.pl
M src/include/catalog/dependency.h
M src/include/catalog/index.h
M src/include/commands/defrem.h
M src/include/nodes/parsenodes.h
A src/test/isolation/expected/reindex-concurrently.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/reindex-concurrently.spec
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
tableam: relation creation, VACUUM FULL/CLUSTER, SET TABLESPACE.
commit : d25f519107bff602e1ebc81853fe592d020c118d
author : Andres Freund <andres@anarazel.de>
date : Thu, 28 Mar 2019 20:01:14 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 28 Mar 2019 20:01:14 -0700 This moves the responsibility for:
- creating the storage necessary for a relation, including creating a
new relfilenode for a relation with existing storage
- non-transactional truncation of a relation
- VACUUM FULL / CLUSTER's rewrite of a table
below tableam.
This is fairly straight forward, with a bit of complexity smattered in
to move the computation of xid / multixid horizons below the AM, as
they don't make sense for every table AM.
Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M src/backend/access/heap/heapam_handler.c
M src/backend/bootstrap/bootparse.y
M src/backend/catalog/heap.c
M src/backend/catalog/index.c
M src/backend/catalog/storage.c
M src/backend/commands/cluster.c
M src/backend/commands/sequence.c
M src/backend/commands/tablecmds.c
M src/backend/utils/cache/relcache.c
M src/include/access/tableam.h
M src/include/catalog/heap.h
M src/include/catalog/storage.h
M src/include/utils/relcache.h
Fix typo.
commit : 7e69323bf72a924fd1b04a7a91da343a0cda91cf
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 29 Mar 2019 10:03:58 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 29 Mar 2019 10:03:58 +1300 Author: Masahiko Sawada M src/backend/access/transam/xact.c
Fix a few comment copy & pastos.
commit : 46bcd2af18b0406207c9dd31ff5e0dab64a76f0a
author : Andres Freund <andres@anarazel.de>
date : Thu, 28 Mar 2019 13:42:37 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 28 Mar 2019 13:42:37 -0700 M src/include/access/tableam.h
Fix deserialization of pg_mcv_list values
commit : 62bf0fb35cb370e9650981ff0333d198e955bd54
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 28 Mar 2019 20:03:14 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 28 Mar 2019 20:03:14 +0100 There were multiple issues in deserialization of pg_mcv_list values.
Firstly, the data is loaded from syscache, but the deserialization was
performed after ReleaseSysCache(), at which point the data might have
already disappeared. Fixed by moving the calls in statext_mcv_load,
and using the same NULL-handling code as existing stats.
Secondly, the deserialized representation used pointers into the
serialized representation. But that is also unsafe, because the data
may disappear at any time. Fixed by reworking and simplifying the
deserialization code to always copy all the data.
And thirdly, when deserializing values for types passed by value, the
code simply did memcpy(d,s,typlen) which however does not work on
bigendian machines. Fixed by using fetch_att/store_att_byval. M src/backend/statistics/mcv.c
M src/include/statistics/statistics.h
doc: Fix typo
commit : f3afbbdae9b6ca04a6d2b224a8dfd5959d8a17ea
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 28 Mar 2019 09:29:49 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 28 Mar 2019 09:29:49 +0100 M doc/src/sgml/storage.sgml
Use FullTransactionId for the transaction stack.
commit : ad308058cc8666c50b43179e64d6bb7aeb3ba169
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 28 Mar 2019 10:59:19 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 28 Mar 2019 10:59:19 +1300 Provide GetTopFullTransactionId() and GetCurrentFullTransactionId().
The intended users of these interfaces are access methods that use
xids for visibility checks but don't want to have to go back and
"freeze" existing references some time later before the 32 bit xid
counter wraps around.
Use a new struct to serialize the transaction state for parallel
query, because FullTransactionId doesn't fit into the previous
serialization scheme very well.
Author: Thomas Munro
Reviewed-by: Heikki Linnakangas
Discussion: https://postgr.es/m/CAA4eK1%2BMv%2Bmb0HFfWM9Srtc6MVe160WFurXV68iAFMcagRZ0dQ%40mail.gmail.com M src/backend/access/transam/varsup.c
M src/backend/access/transam/xact.c
M src/include/access/transam.h
M src/include/access/xact.h
M src/tools/pgindent/typedefs.list
Add basic infrastructure for 64 bit transaction IDs.
commit : 2fc7af5e966043a412e8e69c135fae55a2db6d4f
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 28 Mar 2019 10:34:43 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 28 Mar 2019 10:34:43 +1300 Instead of inferring epoch progress from xids and checkpoints,
introduce a 64 bit FullTransactionId type and use it to track xid
generation. This fixes an unlikely bug where the epoch is reported
incorrectly if the range of active xids wraps around more than once
between checkpoints.
The only user-visible effect of this commit is to correct the epoch
used by txid_current() and txid_status(), also visible with
pg_controldata, in those rare circumstances. It also creates some
basic infrastructure so that later patches can use 64 bit
transaction IDs in more places.
The new type is a struct that we pass by value, as a form of strong
typedef. This prevents the sort of accidental confusion between
TransactionId and FullTransactionId that would be possible if we
were to use a plain old uint64.
Author: Thomas Munro
Reported-by: Amit Kapila
Reviewed-by: Andres Freund, Tom Lane, Heikki Linnakangas
Discussion: https://postgr.es/m/CAA4eK1%2BMv%2Bmb0HFfWM9Srtc6MVe160WFurXV68iAFMcagRZ0dQ%40mail.gmail.com M src/backend/access/rmgrdesc/xlogdesc.c
M src/backend/access/transam/clog.c
M src/backend/access/transam/commit_ts.c
M src/backend/access/transam/multixact.c
M src/backend/access/transam/subtrans.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/varsup.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/replication/walreceiver.c
M src/backend/replication/walsender.c
M src/backend/storage/ipc/procarray.c
M src/backend/storage/ipc/standby.c
M src/backend/storage/lmgr/predicate.c
M src/backend/utils/adt/txid.c
M src/backend/utils/misc/pg_controldata.c
M src/bin/pg_controldata/pg_controldata.c
M src/bin/pg_resetwal/pg_resetwal.c
M src/include/access/transam.h
M src/include/access/xlog.h
M src/include/catalog/pg_control.h
M src/include/storage/standby.h
M src/include/storage/standbydefs.h
M src/tools/pgindent/typedefs.list
tableam: Support for an index build’s initial table scan(s).
commit : 2a96909a4a8c38705163b83a81b228d5aec197f9
author : Andres Freund <andres@anarazel.de>
date : Wed, 27 Mar 2019 19:59:06 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 27 Mar 2019 19:59:06 -0700 To support building indexes over tables of different AMs, the scans to
do so need to be routed through the table AM. While moving a fair
amount of code, nearly all the changes are just moving code to below a
callback.
Currently the range based interface wouldn't make much sense for non
block based table AMs. But that seems aceptable for now.
Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M contrib/amcheck/verify_nbtree.c
M contrib/bloom/blinsert.c
M doc/src/sgml/indexam.sgml
M src/backend/access/brin/brin.c
M src/backend/access/gin/gininsert.c
M src/backend/access/gist/gistbuild.c
M src/backend/access/hash/hash.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/spgist/spginsert.c
M src/backend/catalog/index.c
M src/include/access/tableam.h
M src/include/catalog/index.h
M src/tools/pgindent/typedefs.list
Fix vpath build
commit : 12bb35fc9b000d462b9bd6b8856e1884ef1bb3d7
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 27 Mar 2019 23:36:00 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 27 Mar 2019 23:36:00 +0100 Skip doc/src/sgml/images/Makefile since the directory is not created. M config/prep_buildtree
doc: Add some images
commit : ea55aec0a97d6cade0186df1913da2c8cb5c6f2c
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 27 Mar 2019 22:57:43 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 27 Mar 2019 22:57:43 +0100 Add infrastructure for having images in the documentation, in SVG
format. Add two images to start with. See the included README file
for instructions.
Author: Jürgen Purtz <juergen@purtz.de>
Author: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/aaa54502-05c0-4ea5-9af8-770411a6bf4b@purtz.de M .gitattributes
M doc/src/sgml/Makefile
M doc/src/sgml/gin.sgml
A doc/src/sgml/images/Makefile
A doc/src/sgml/images/README
A doc/src/sgml/images/gin.dot
A doc/src/sgml/images/gin.svg
A doc/src/sgml/images/pagelayout.svg
A doc/src/sgml/images/pagelayout.txt
M doc/src/sgml/storage.sgml
M doc/src/sgml/stylesheet-hh.xsl
M doc/src/sgml/stylesheet-html-common.xsl
M doc/src/sgml/stylesheet-html-nochunk.xsl
M doc/src/sgml/stylesheet.xsl
doc: Move htmlhelp output to subdirectory
commit : 477422c9d176784e90e630de3c92b4fae8590bd2
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 27 Mar 2019 22:03:10 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 27 Mar 2019 22:03:10 +0100 This makes it behave more like the html output. That will make some
subsequent changes across all output formats easier. M doc/src/sgml/Makefile
M doc/src/sgml/stylesheet-hh.xsl
Use Pandoc also for plain-text documentation output
commit : 2488ea7a9056ab4c0f1bbf56548e829fa40f9c4c
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 27 Mar 2019 21:12:10 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 27 Mar 2019 21:12:10 +0100 The makefile rule for the (rarely used) plain-text output postgres.txt
was still written to use lynx, but in
96b8b8b6f9d8de4af01a77797273ad88c7a8e32e, where the INSTALL file was
switched to pandoc, the rest of the makefile support for lynx was
removed, so this was broken. Rewrite the rule to also use pandoc for
postgres.txt. M doc/src/sgml/Makefile
Minor improvements for the multivariate MCV lists
commit : a63b29a1dea0ce4e95f682f9d0b36994f2fcf43e
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 27 Mar 2019 20:07:41 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 27 Mar 2019 20:07:41 +0100 The MCV build should always call get_mincount_for_mcv_list(), as the
there is no other logic to decide whether the MCV list represents all
the data. So just remove the (ngroups > nitems) condition.
Also, when building MCV lists, the number of items was limited by the
statistics target (i.e. up to 10000). But when deserializing the MCV
list, a different value (8192) was used to check the input, causing
an error. Simply ensure that the same value is used in both places.
This should have been included in 7300a69950, but I forgot to include it
in that commit. M src/backend/statistics/mcv.c
M src/include/statistics/statistics.h
Add support for multivariate MCV lists
commit : 7300a699502fe5432b05fbc75baca534b080bebb
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 27 Mar 2019 18:32:18 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 27 Mar 2019 18:32:18 +0100 Introduce a third extended statistic type, supported by the CREATE
STATISTICS command - MCV lists, a generalization of the statistic
already built and used for individual columns.
Compared to the already supported types (n-distinct coefficients and
functional dependencies), MCV lists are more complex, include column
values and allow estimation of much wider range of common clauses
(equality and inequality conditions, IS NULL, IS NOT NULL etc.).
Similarly to the other types, a new pseudo-type (pg_mcv_list) is used.
Author: Tomas Vondra
Reviewed-by: Dean Rasheed, David Rowley, Mark Dilger, Alvaro Herrera
Discussion: https://postgr.es/m/dfdac334-9cf2-2597-fb27-f0fb3753f435@2ndquadrant.com M doc/src/sgml/catalogs.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/perform.sgml
M doc/src/sgml/planstats.sgml
M doc/src/sgml/ref/create_statistics.sgml
M src/backend/commands/statscmds.c
M src/backend/nodes/bitmapset.c
M src/backend/optimizer/path/clausesel.c
M src/backend/optimizer/util/plancat.c
M src/backend/parser/parse_utilcmd.c
M src/backend/statistics/Makefile
M src/backend/statistics/README
A src/backend/statistics/README.mcv
M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
A src/backend/statistics/mcv.c
M src/backend/utils/adt/ruleutils.c
M src/bin/psql/describe.c
M src/bin/psql/tab-complete.c
M src/include/catalog/pg_cast.dat
M src/include/catalog/pg_proc.dat
M src/include/catalog/pg_statistic_ext.h
M src/include/catalog/pg_type.dat
M src/include/nodes/bitmapset.h
M src/include/optimizer/optimizer.h
M src/include/statistics/extended_stats_internal.h
M src/include/statistics/statistics.h
M src/test/regress/expected/create_table_like.out
M src/test/regress/expected/opr_sanity.out
M src/test/regress/expected/stats_ext.out
M src/test/regress/expected/type_sanity.out
M src/test/regress/sql/stats_ext.sql
Avoid passing query tlist around separately from root->processed_tlist.
commit : 333ed246c6f351c4e8fe22c764b97793c4101b00
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 Mar 2019 12:57:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 Mar 2019 12:57:41 -0400 In the dim past, the planner kept the fully-processed version of the query
targetlist (the result of preprocess_targetlist) in grouping_planner's
local variable "tlist", and only grudgingly passed it to individual other
routines as needed. Later we discovered a need to still have it available
after grouping_planner finishes, and invented the root->processed_tlist
field for that purpose, but it wasn't used internally to grouping_planner;
the tlist was still being passed around separately in the same places as
before.
Now comes a proposed patch to allow appendrel expansion to add entries
to the processed tlist, well after preprocess_targetlist has finished
its work. To avoid having to pass around the tlist explicitly, it's
proposed to allow appendrel expansion to modify root->processed_tlist.
That makes aliasing the tlist with assorted parameters and local
variables really scary. It would accidentally work as long as the
tlist is initially nonempty, because then the List header won't move
around, but it's not exactly hard to think of ways for that to break.
Aliased values are poor programming practice anyway.
Hence, get rid of local variables and parameters that can be identified
with root->processed_tlist, in favor of just using that field directly.
And adjust comments to match. (Some of the new comments speak as though
it's already possible for appendrel expansion to modify the tlist; that's
not true yet, but will happen in a later patch.)
Discussion: https://postgr.es/m/9d7c5112-cb99-6a47-d3be-cf1ee6862a1d@lab.ntt.co.jp M src/backend/optimizer/plan/planagg.c
M src/backend/optimizer/plan/planmain.c
M src/backend/optimizer/plan/planner.c
M src/include/nodes/pathnodes.h
M src/include/optimizer/planmain.h
pgbench: doExecuteCommand -> executeMetaCommand
commit : 9938d116331045171f37eef359992ec64c213384
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Mar 2019 12:17:19 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 27 Mar 2019 12:17:19 -0300 The new function is only in charge of meta commands, not SQL commands.
This change makes the code a little clearer: now all the state changes
are effected by advanceConnectionState. It also removes one indent
level, which makes the diff look bulkier than it really is.
Author: Fabien Coelho
Reviewed-by: Kirk Jamison
Discussion: https://postgr.es/m/alpine.DEB.2.21.1811240904500.12627@lancre M src/bin/pgbench/pgbench.c
Suppress uninitialized-variable warning.
commit : a51cc7e9e60701d31032669011adcda8b4621d93
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 Mar 2019 11:10:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 27 Mar 2019 11:10:42 -0400 Apparently Andres' compiler is smart enough to see that hpage
must be initialized before use ... but mine isn't. M src/backend/access/heap/heapam.c
Improve error handling of column references in expression transformation
commit : ecfed4a12247cf4659eee6b6ea27405e35fe57f8
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 27 Mar 2019 21:04:25 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 27 Mar 2019 21:04:25 +0900 Column references are not allowed in default expressions and partition
bound expressions, and are restricted as such once the transformation of
their expressions is done. However, trying to use more complex column
references can lead to confusing error messages. For example, trying to
use a two-field column reference name for default expressions and
partition bounds leads to "missing FROM-clause entry for table", which
makes no sense in their respective context.
In order to make the errors generated more useful, this commit adds more
verbose messages when transforming column references depending on the
context. This has a little consequence though: for example an
expression using an aggregate with a column reference as argument would
cause an error to be generated for the column reference, while the
aggregate was the problem reported before this commit because column
references get transformed first.
The confusion exists for default expressions for a long time, and the
problem is new as of v12 for partition bounds. Still per the lack of
complaints on the matter no backpatch is done.
The patch has been written by Amit Langote and me, and Tom Lane has
provided the improvement of the documentation for default expressions on
the CREATE TABLE page.
Author: Amit Langote, Michael Paquier
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/20190326020853.GM2558@paquier.xyz M doc/src/sgml/ref/create_table.sgml
M src/backend/catalog/heap.c
M src/backend/parser/parse_expr.c
M src/backend/parser/parse_utilcmd.c
M src/test/regress/expected/create_table.out
M src/test/regress/sql/create_table.sql
Fix off-by-one error in txid_status().
commit : d2fd7f74ee61f41a3bd5daf2942b72cebd88f346
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 27 Mar 2019 21:16:50 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 27 Mar 2019 21:16:50 +1300 The transaction ID returned by GetNextXidAndEpoch() is in the future,
so we can't attempt to access its status or we might try to read a
CLOG page that doesn't exist. The > vs >= confusion probably stemmed
from the choice of a variable name containing the word "last" instead
of "next", so fix that too.
Back-patch to 10 where the function arrived.
Author: Thomas Munro
Discussion: https://postgr.es/m/CA%2BhUKG%2Buua_BV5cyfsioKVN2d61Lukg28ECsWTXKvh%3DBtN2DPA%40mail.gmail.com M src/backend/utils/adt/txid.c
Switch some palloc/memset calls to palloc0
commit : 1983af8e899389187026cb34c1ca9d89ea986120
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 27 Mar 2019 12:02:50 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 27 Mar 2019 12:02:50 +0900 Some code paths have been doing some allocations followed by an
immediate memset() to initialize the allocated area with zeros, this is
a bit overkill as there are already interfaces to do both things in one
call.
Author: Daniel Gustafsson
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/vN0OodBPkKs7g2Z1uyk3CUEmhdtspHgYCImhlmSxv1Xn6nY1ZnaaGHL8EWUIQ-NEv36tyc4G5-uA3UXUF2l4sFXtK_EQgLN1hcgunlFVKhA=@yesql.se M contrib/tablefunc/tablefunc.c
M src/backend/access/gist/gist.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_dump_sort.c
M src/bin/pgbench/pgbench.c
Switch function current_schema[s]() to be parallel-unsafe
commit : 5bde1651bbba9984dc32bbeb68b329cfd3f92767
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 27 Mar 2019 11:35:12 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 27 Mar 2019 11:35:12 +0900 When invoked for the first time in a session, current_schema() and
current_schemas() can finish by creating a temporary schema. Currently
those functions are parallel-safe, however if for a reason or another
they get launched across multiple parallel workers, they would fail when
attempting to create a temporary schema as temporary contexts are not
supported in this case.
The original issue has been spotted by buildfarm members crake and
lapwing, after commit c5660e0 has introduced the first regression tests
based on current_schema() in the tree. After that, 396676b has
introduced a workaround to avoid parallel plans but that was not
completely right either.
Catversion is bumped.
Author: Michael Paquier
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/20190118024618.GF1883@paquier.xyz M src/include/catalog/catversion.h
M src/include/catalog/pg_proc.dat
M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql
Track unowned relations in doubly-linked list
commit : 6ca015f9f073eef40f933f587e0b166b87261406
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 27 Mar 2019 02:39:39 +0100
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 27 Mar 2019 02:39:39 +0100 Relations dropped in a single transaction are tracked in a list of
unowned relations. With large number of dropped relations this resulted
in poor performance at the end of a transaction, when the relations are
removed from the singly linked list one by one.
Commit b4166911 attempted to address this issue (particularly when it
happens during recovery) by removing the relations in a reverse order,
resulting in O(1) lookups in the list of unowned relations. This did
not work reliably, though, and it was possible to trigger the O(N^2)
behavior in various ways.
Instead of trying to remove the relations in a specific order with
respect to the linked list, which seems rather fragile, switch to a
regular doubly linked. That allows us to remove relations cheaply no
matter where in the list they are.
As b4166911 was a bugfix, backpatched to all supported versions, do the
same thing here.
Reviewed-by: Alvaro Herrera
Discussion: https://www.postgresql.org/message-id/flat/80c27103-99e4-1d0c-642c-d9f3b94aaa0a%402ndquadrant.com
Backpatch-through: 9.4 M src/backend/storage/smgr/md.c
M src/backend/storage/smgr/smgr.c
M src/include/storage/smgr.h
Compute XID horizon for page level index vacuum on primary.
commit : 558a9165e081d1936573e5a7d576f5febd7fb55a
author : Andres Freund <andres@anarazel.de>
date : Tue, 26 Mar 2019 14:41:46 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 26 Mar 2019 14:41:46 -0700 Previously the xid horizon was only computed during WAL replay. That
had two major problems:
1) It relied on knowing what the table pointed to looks like. That was
easy enough before the introducing of tableam (we knew it had to be
heap, although some trickery around logging the heap relfilenodes
was required). But to properly handle table AMs we need
per-database catalog access to look up the AM handler, which
recovery doesn't allow.
2) Not knowing the xid horizon also makes it hard to support logical
decoding on standbys. When on a catalog table, we need to be able
to conflict with slots that have an xid horizon that's too old. But
computing the horizon by visiting the heap only works once
consistency is reached, but we always need to be able to detect
conflicts.
There's also a secondary problem, in that the current method performs
redundant work on every standby. But that's counterbalanced by
potentially computing the value when not necessary (either because
there's no standby, or because there's no connected backends).
Solve 1) and 2) by moving computation of the xid horizon to the
primary and by involving tableam in the computation of the horizon.
To address the potentially increased overhead, increase the efficiency
of the xid horizon computation for heap by sorting the tids, and
eliminating redundant buffer accesses. When prefetching is available,
additionally perform prefetching of buffers. As this is more of a
maintenance task, rather than something routinely done in every read
only query, we add an arbitrary 10 to the effective concurrency -
thereby using IO concurrency, when not globally enabled. That's
possibly not the perfect formula, but seems good enough for now.
Bumps WAL format, as latestRemovedXid is now part of the records, and
the heap's relfilenode isn't anymore.
Author: Andres Freund, Amit Khandekar, Robert Haas
Reviewed-By: Robert Haas
Discussion:
https://postgr.es/m/20181212204154.nsxf3gzqv3gesl32@alap3.anarazel.de
https://postgr.es/m/20181214014235.dal5ogljs3bmlq44@alap3.anarazel.de
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M src/backend/access/hash/hash_xlog.c
M src/backend/access/hash/hashinsert.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/index/genam.c
M src/backend/access/nbtree/nbtpage.c
M src/backend/access/nbtree/nbtxlog.c
M src/backend/access/rmgrdesc/hashdesc.c
M src/backend/access/rmgrdesc/nbtdesc.c
M src/include/access/genam.h
M src/include/access/hash_xlog.h
M src/include/access/heapam.h
M src/include/access/nbtxlog.h
M src/include/access/tableam.h
M src/include/access/xlog_internal.h
M src/tools/pgindent/typedefs.list
Fix partitioned index creation bug with dropped columns
commit : 126d631222328d3def7910934bfa9cbdc99d79cc
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 26 Mar 2019 20:19:28 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 26 Mar 2019 20:19:28 -0300 ALTER INDEX .. ATTACH PARTITION fails if the partitioned table where the
index is defined contains more dropped columns than its partition, with
this message:
ERROR: incorrect attribute map
The cause was that one caller of CompareIndexInfo was passing the number
of attributes of the partition rather than the parent, which confused
the length check. Repair.
This can cause pg_upgrade to fail when used on such a database. Leave
some more objects around after regression tests, so that the case is
detected by pg_upgrade test suite.
Remove some spurious empty lines noticed while looking for other cases
of the same problem.
Discussion: https://postgr.es/m/20190326213924.GA2322@alvherre.pgsql M src/backend/catalog/index.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql
Build “other rels” of appendrel baserels in a separate step.
commit : 53bcf5e3dbeaed5baf9d09b124cf196d247c54ea
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Mar 2019 18:21:10 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Mar 2019 18:21:10 -0400 Up to now, otherrel RelOptInfos were built at the same time as baserel
RelOptInfos, thanks to recursion in build_simple_rel(). However,
nothing in query_planner's preprocessing cares at all about otherrels,
only baserels, so we don't really need to build them until just before
we enter make_one_rel. This has two benefits:
* create_lateral_join_info did a lot of extra work to propagate
lateral-reference information from parents to the correct children.
But if we delay creation of the children till after that, it's
trivial (and much harder to break, too).
* Since we have all the restriction quals correctly assigned to
parent appendrels by this point, it'll be possible to do plan-time
pruning and never make child RelOptInfos at all for partitions that
can be pruned away. That's not done here, but will be later on.
Amit Langote, reviewed at various times by Dilip Kumar, Jesper Pedersen,
Yoshikazu Imai, and David Rowley
Discussion: https://postgr.es/m/9d7c5112-cb99-6a47-d3be-cf1ee6862a1d@lab.ntt.co.jp M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/plan/initsplan.c
M src/backend/optimizer/plan/planmain.c
M src/backend/optimizer/util/relnode.c
M src/include/optimizer/pathnode.h
M src/include/optimizer/planmain.h
Add ORDER BY to more ICU regression test cases.
commit : 8994cc6ffc8828569a39139996a0b0b8348ca036
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Mar 2019 17:46:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Mar 2019 17:46:04 -0400 Commit c77e12208 didn't fully fix the problem. Per buildfarm
and local testing. M src/test/regress/expected/collate.icu.utf8.out
M src/test/regress/sql/collate.icu.utf8.sql
Fix oversight in data-type change for autovacuum_vacuum_cost_delay.
commit : 7c366ac969ce060c4080fbdfe74a0131ae4bf6bb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Mar 2019 13:32:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Mar 2019 13:32:30 -0400 Commit caf626b2c missed that the relevant reloptions entry needs
to be moved from the intRelOpts[] array to realRelOpts[].
Somewhat surprisingly, it seems to work anyway, perhaps because
the desired default and limit values are all integers. We ought
to have either a simpler data structure or better cross-checking
here, but that's for another patch.
Nikolay Shaplov
Discussion: https://postgr.es/m/4861742.12LTaSB3sv@x200m M src/backend/access/common/reloptions.c
psql: Schema-qualify typecast in one \d query
commit : 1d21ba8a9b8cb784f927a2c9c5818f8ff6779c0b
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 26 Mar 2019 13:04:06 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 26 Mar 2019 13:04:06 -0300 Bug introduced in my commit bc87f22ef6ef M src/bin/psql/describe.c
Get rid of duplicate child RTE for a partitioned table.
commit : e8d5dd6be79ed532710922105c31a2d25b14430f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Mar 2019 12:03:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 26 Mar 2019 12:03:27 -0400 We've been creating duplicate RTEs for partitioned tables just
because we do so for regular inheritance parent tables. But unlike
regular-inheritance parents which are themselves regular tables
and thus need to be scanned, partitioned tables don't need the
extra RTE.
This makes the conditions for building a child RTE the same as those
for building an AppendRelInfo, allowing minor simplification in
expand_single_inheritance_child. Since the planner's actual processing
is driven off the AppendRelInfo list, nothing much changes beyond that,
we just have one fewer useless RTE entry.
Amit Langote, reviewed and hacked a bit by me
Discussion: https://postgr.es/m/9d7c5112-cb99-6a47-d3be-cf1ee6862a1d@lab.ntt.co.jp M contrib/postgres_fdw/expected/postgres_fdw.out
M src/backend/optimizer/util/inherit.c
Improve psql’s \d display of foreign key constraints
commit : 1af25ca0c2d9d110bd7bd5be2a14fb20cd93ee78
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 26 Mar 2019 11:14:34 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 26 Mar 2019 11:14:34 -0300 When used on a partition containing foreign keys coming from one of its
ancestors, \d would (rather unhelpfully) print the details about the
pg_constraint row in the partition. This becomes a bit frustrating when
the user tries things like dropping the FK in the partition; instead,
show the details for the foreign key on the table where it is defined.
Also, when a table is referenced by a foreign key on a partitioned
table, we would show multiple "Referenced by" lines, one for each
partition, which gets unwieldy pretty fast. Modify that so that it
shows only one line for the ancestor partitioned table where the FK is
defined.
Discussion: https://postgr.es/m/20181204143834.ym6euxxxi5aeqdpn@alvherre.pgsql
Reviewed-by: Tom Lane, Amit Langote, Peter Eisentraut M src/bin/psql/describe.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Fix typo
commit : 05295e36ca9b40c53b7c36f5c7f75f822cd49baf
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 26 Mar 2019 13:30:46 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 26 Mar 2019 13:30:46 +0100 Author: Daniel Gustafsson <daniel@yesql.se> M doc/src/sgml/ecpg.sgml
Fix misplaced const
commit : c8c885b7a5c8c1175288de1d8aaec3b4ae9050e1
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 26 Mar 2019 09:23:08 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 26 Mar 2019 09:23:08 +0100 These instances were apparently trying to carry the const qualifier
from the arguments through the complex casts, but for that the const
qualifier was misplaced. M src/backend/partitioning/partbounds.c
M src/backend/utils/adt/tsquery_op.c
Remove heap_hot_search().
commit : 2ac1b2b175ea5456516e59fe2b53a1e0578a5dbd
author : Andres Freund <andres@anarazel.de>
date : Mon, 25 Mar 2019 19:02:36 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 25 Mar 2019 19:02:36 -0700 After 71bdc99d0d7, "tableam: Add helper for indexes to check if a
corresponding table tuples exist." there's no in-core user left. As
there's unlikely to be an external user, and such an external user
could easily be adjusted to use table_index_fetch_tuple_check(),
remove heap_hot_search().
Per complaint from Peter Geoghegan
Author: Andres Freund
Discussion: https://postgr.es/m/CAH2-Wzn0Oq4ftJrTqRAsWy2WGjv0QrJcwoZ+yqWsF_Z5vjUBFw@mail.gmail.com M src/backend/access/heap/heapam.c
M src/include/access/heapam.h
Fix crash when using partition bound expressions
commit : cdde886d36b5a4d7ad9e1d02596f7fa1c8c129e3
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 26 Mar 2019 10:09:14 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 26 Mar 2019 10:09:14 +0900 Since 7c079d7, partition bounds are able to use generalized expression
syntax when processed, treating "minvalue" and "maxvalue" as specific
cases as they get passed down for transformation as a column references.
The checks for infinite bounds in range expressions have been lax
though, causing crashes when trying to use column reference names with
more than one field. Here is an example causing a crash:
CREATE TABLE list_parted (a int) PARTITION BY LIST (a);
CREATE TABLE part_list_crash PARTITION OF list_parted
FOR VALUES IN (somename.somename);
Note that the creation of the second relation should fail as partition
bounds cannot have column references in their expressions, so when
finding an expression which does not match the expected infinite bounds,
then this commit lets the generic transformation machinery check after
it. The error message generated in this case references as well a
missing RTE, which is confusing. This problem will be treated
separately as it impacts as well default expressions for some time, and
for now only the cases where a crash can happen are fixed.
While on it, extend the set of regression tests in place for list
partition bounds and add an extra set for range partition bounds.
Reported-by: Alexander Lakhin
Author: Michael Paquier
Reviewed-by: Amit Langote
Discussion: https://postgr.es/m/15668-0377b1981aa1a393@postgresql.org M src/backend/parser/parse_utilcmd.c
M src/test/regress/expected/create_table.out
M src/test/regress/sql/create_table.sql
tableam: Add table_get_latest_tid, to wrap heap_get_latest_tid.
commit : 2e3da03e9ee4d6ee5cf0d1ffe0227fe6275397e1
author : Andres Freund <andres@anarazel.de>
date : Mon, 25 Mar 2019 17:14:48 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 25 Mar 2019 17:14:48 -0700 This primarily is to allow WHERE CURRENT OF to continue to work as it
currently does. It's not clear to me that these semantics make sense
for every AM, but it works for the in-core heap, and the out of core
zheap. We can refine it further at a later point if necessary.
Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M src/backend/access/heap/heapam_handler.c
M src/backend/executor/nodeTidscan.c
M src/backend/utils/adt/tid.c
M src/include/access/tableam.h
tableam: Add helper for indexes to check if a corresponding table tuples exist.
commit : 71bdc99d0d7c3b2d73fa04fb2ff80870ce1305f7
author : Andres Freund <andres@anarazel.de>
date : Mon, 25 Mar 2019 16:52:55 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 25 Mar 2019 16:52:55 -0700 This is, likely exclusively, useful to verify that conflicts detected
in a unique index are with live tuples, rather than dead ones.
Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/table/tableam.c
M src/include/access/tableam.h
Add MacPorts support to src/test/ldap tests.
commit : aa1419e63f85b23503076bb4b6413aca30b535fe
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 26 Mar 2019 10:39:03 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 26 Mar 2019 10:39:03 +1300 Previously the test knew how to find an OpenLDAP installation at the
paths used by Homebrew. Add the MacPorts paths too.
Author: Thomas Munro
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/CA%2BhUKGKrjGS7sO4jc53gp3qipCtEvThtdP_%3DzoixgX5ZBq4Nbw%40mail.gmail.com M src/test/ldap/README
M src/test/ldap/t/001_auth.pl
Improve planner’s selectivity estimates for inequalities on CTID.
commit : f7111f72d2fd31979c6d473cdde56ba8e7aba26a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Mar 2019 18:42:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Mar 2019 18:42:52 -0400 We were getting just DEFAULT_INEQ_SEL for comparisons such as
"ctid >= constant", but it's possible to do a lot better if we don't
mind some assumptions about the table's tuple density being reasonably
uniform. There are already assumptions much like that elsewhere in
the planner, so that hardly seems like much of an objection.
Extracted from a patch set that also proposes to introduce a special
executor node type for such queries. Not sure if that's going to make
it into v12, but improving the selectivity estimate is useful
independently of that.
Edmund Horner, reviewed by David Rowley
Discussion: https://postgr.es/m/CAMyN-kB-nFTkF=VA_JPwFNo08S0d-Yk0F741S2B7LDmYAi8eyA@mail.gmail.com M src/backend/utils/adt/selfuncs.c
Doc: clarify that REASSIGN OWNED doesn’t handle default privileges.
commit : b3bd819632701d53580d9433f3f80c529865f86d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Mar 2019 17:18:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Mar 2019 17:18:05 -0400 It doesn't touch regular privileges either, but only the latter was
explicitly stated.
Discussion: https://postgr.es/m/155348282848.9808.12629518043813943231@wrigleys.postgresql.org M doc/src/sgml/ref/drop_owned.sgml
M doc/src/sgml/ref/reassign_owned.sgml
Suppress Append and MergeAppend plan nodes that have a single child.
commit : 8edd0e79460b414b1d971895312e549e95e12e4f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Mar 2019 15:42:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Mar 2019 15:42:35 -0400 If there's only one child relation, the Append or MergeAppend isn't
doing anything useful, and can be elided. It does have a purpose
during planning though, which is to serve as a buffer between parent
and child Var numbering. Therefore we keep it all the way through
to setrefs.c, and get rid of it only after fixing references in the
plan level(s) above it. This works largely the same as setrefs.c's
ancient hack to get rid of no-op SubqueryScan nodes, and can even
share some code with that.
Note the change to make setrefs.c use apply_tlist_labeling rather than
ad-hoc code. This has the effect of propagating the child's resjunk
and ressortgroupref labels, which formerly weren't propagated when
removing a SubqueryScan. Doing that is demonstrably necessary for
the [Merge]Append cases, and seems harmless for SubqueryScan, if only
because trivial_subqueryscan is afraid to collapse cases where the
resjunk marking differs. (I suspect that restriction could now be
removed, though it's unclear that it'd make any new matches possible,
since the outer query can't have references to a child resjunk column.)
David Rowley, reviewed by Alvaro Herrera and Tomas Vondra
Discussion: https://postgr.es/m/CAKJS1f_7u8ATyJ1JGTMHFoKDvZdeF-iEBhs+sM_SXowOr9cArg@mail.gmail.com M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/executor/execAmi.c
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/setrefs.c
M src/backend/optimizer/util/pathnode.c
M src/test/regress/expected/inherit.out
M src/test/regress/expected/partition_join.out
M src/test/regress/expected/partition_prune.out
M src/test/regress/expected/rowsecurity.out
M src/test/regress/expected/union.out
Add “split after new tuple” nbtree optimization.
commit : f21668f328c864c6b9290f39d41774cb2422f98e
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 25 Mar 2019 09:44:25 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 25 Mar 2019 09:44:25 -0700 Add additional heuristics to the algorithm for locating an optimal split
location. New logic identifies localized monotonically increasing
values in indexes with multiple columns. When this insertion pattern is
detected, page splits split just after the new item that provoked a page
split (or apply leaf fillfactor in the style of a rightmost page split).
This optimization is a variation of the long established leaf fillfactor
optimization used during rightmost page splits.
50/50 page splits are only appropriate with a pattern of truly random
insertions, where the average space utilization ends up at 65% - 70%.
Without this patch, affected cases have leaf pages that are no more than
about 50% full on average. Future insertions can never make use of the
free space left behind. With this patch, affected cases have leaf pages
that are about 90% full on average (assuming a fillfactor of 90).
Localized monotonically increasing insertion patterns are presumed to be
fairly common in real-world applications. There is a fair amount of
anecdotal evidence for this. Both pg_depend system catalog indexes
(pg_depend_depender_index and pg_depend_reference_index) are at least
20% smaller after the regression tests are run when the optimization is
available. Furthermore, many of the indexes created by a fair use
implementation of TPC-C for Postgres are consistently about 40% smaller
when the optimization is available.
Note that even pg_upgrade'd v3 indexes make use of this optimization.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas
Discussion: https://postgr.es/m/CAH2-WzkpKeZJrXvR_p7VSY1b-s85E3gHyTbZQzR0BkJ5LrWF_A@mail.gmail.com M src/backend/access/nbtree/nbtsplitloc.c
Further code review for new integerset code.
commit : f7ff0ae8428f9001eab244cb2535f40d29f218e9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Mar 2019 12:23:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 25 Mar 2019 12:23:40 -0400 Mostly cosmetic adjustments, but I added a more reliable method of
detecting whether an iteration is in progress. M src/backend/lib/integerset.c
M src/test/modules/test_integerset/README
M src/test/modules/test_integerset/test_integerset.c
Refactor code to print pgbench progress reports.
commit : 9f75e3772350fb66f20a3d7f33bc94f30300d7eb
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 25 Mar 2019 18:07:29 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 25 Mar 2019 18:07:29 +0200 threadRun() function is very long and deeply-nested. Extract the code to
print progress reports to a separate function, to make it slightly easier
to read.
Author: Fabien Coelho
Discussion: https://www.postgresql.org/message-id/alpine.DEB.2.21.1903101225270.17271%40lancre M src/bin/pgbench/pgbench.c
Fix use of wrong datatype with sizeof().
commit : 5857be907d5178673ce077ba71562f3c4297ee32
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 25 Mar 2019 11:23:52 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 25 Mar 2019 11:23:52 -0400 OID and int are the same size, but they are not the same thing.
David Rowley
Discussion: http://postgr.es/m/CAKJS1f_MhS++XngkTvWL9X1v8M5t-0N0B-R465yHQY=TmNV0Ew@mail.gmail.com M src/backend/nodes/copyfuncs.c
M src/backend/partitioning/partprune.c
pgbench: Remove \cset
commit : 25ee70511ec2ccbef0ad3fe64875a4d552cdcd50
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 25 Mar 2019 12:16:07 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 25 Mar 2019 12:16:07 -0300 Partial revert of commit 6260cc550b0e, "pgbench: add \cset and \gset
commands".
While \gset is widely considered a useful and necessary tool for user-
defined benchmarks, \cset does not have as much value, and its
implementation was considered "not to be up to project standards"
(though I, Álvaro, can't quite understand exactly how). Therefore,
remove \cset.
Author: Fabien Coelho
Discussion: https://postgr.es/m/alpine.DEB.2.21.1903230716030.18811@lancre
Discussion: https://postgr.es/m/201901101900.mv7zduch6sad@alvherre.pgsql M doc/src/sgml/ref/pgbench.sgml
M src/bin/pgbench/pgbench.c
M src/bin/pgbench/t/001_pgbench_with_server.pl
M src/fe_utils/psqlscan.l
M src/include/fe_utils/psqlscan.h
M src/include/fe_utils/psqlscan_int.h
Add progress reporting for CLUSTER and VACUUM FULL.
commit : 6f97457e0ddd8b421ca5e483439ef0318e6fc89a
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 25 Mar 2019 10:59:04 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 25 Mar 2019 10:59:04 -0400 This uses the same progress reporting infrastructure added in commit
c16dc1aca5e01e6acaadfcf38f5fc964a381dc62 and extends it to these
additional cases. We lack the ability to track the internal progress
of sorts and index builds so the information reported is
coarse-grained for some parts of the operation, but it still seems
like a significant improvement over having nothing at all.
Tatsuro Yamada, reviewed by Thomas Munro, Masahiko Sawada, Michael
Paquier, Jeff Janes, Alvaro Herrera, Rafia Sabih, and by me. A fair
amount of polishing also by me.
Discussion: http://postgr.es/m/59A77072.3090401@lab.ntt.co.jp M doc/src/sgml/monitoring.sgml
M src/backend/catalog/index.c
M src/backend/catalog/system_views.sql
M src/backend/commands/cluster.c
M src/backend/utils/adt/pgstatfuncs.c
M src/include/catalog/catversion.h
M src/include/commands/progress.h
M src/include/pgstat.h
M src/test/regress/expected/rules.out
Get rid of backtracking in jsonpath_scan.l
commit : 1d88a75c424664cc85f307a876cde85191d27272
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 25 Mar 2019 15:43:56 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 25 Mar 2019 15:43:56 +0300 Non-backtracking flex parsers work faster than backtracking ones. So, this
commit gets rid of backtracking in jsonpath_scan.l. That required explicit
handling of some cases as well as manual backtracking for some cases. More
regression tests for numerics are added.
Discussion: https://mail.google.com/mail/u/0?ik=a20b091faa&view=om&permmsgid=msg-f%3A1628425344167939063
Author: John Naylor, Nikita Gluknov, Alexander Korotkov M src/backend/utils/adt/Makefile
M src/backend/utils/adt/jsonpath_scan.l
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/expected/jsonpath.out
A src/test/regress/expected/jsonpath_encoding.out
A src/test/regress/expected/jsonpath_encoding_1.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/jsonb_jsonpath.sql
M src/test/regress/sql/jsonpath.sql
A src/test/regress/sql/jsonpath_encoding.sql
Cosmetic changes for jsonpath_gram.y and jsonpath_scan.l
commit : 8b17298f0b6bb2a64b55fab0339c8fd6ec2d74fb
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 25 Mar 2019 15:42:51 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 25 Mar 2019 15:42:51 +0300 This commit include formatting improvements, renamings and comments. Also,
it makes jsonpath_scan.l be more uniform with other our lexers. Firstly,
states names are renamed to more short alternatives. Secondly, <INITIAL>
prefix removed from the rules. Corresponding rules are moved to the tail, so
they would anyway work only in initial state.
Author: Alexander Korotkov
Reviewed-by: John Naylor M src/backend/utils/adt/jsonpath_gram.y
M src/backend/utils/adt/jsonpath_scan.l
Clean up the Simple-8b encoder code.
commit : d303122eab616ccbcfb0bab0fc674bf625d17a7b
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 25 Mar 2019 11:39:51 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 25 Mar 2019 11:39:51 +0200 Coverity complained that simple8b_encode() might read beyond the end of
the 'diffs' array, in the loop to encode the integers. That was a false
positive, because we never get into the loop in modes 0 or 1, and the
array is large enough for all the other modes. But I admit it's very
subtle, so it's not surprising that Coverity didn't see it, and it's not
very obvious to humans either. Refactor it, so that the second loop
re-computes the differences, instead of carrying them over from the first
loop in the 'diffs' array. This way, the 'diffs' array is not needed
anymore. It makes no measurable difference in performance, and seems more
straightforward this way.
Also, improve the comments in simple8b_encode(): fix the comment about its
return value that was flat-out wrong, and explain the condition when it
returns EMPTY_CODEWORD better.
In the passing, move the 'selector' from the codeword's low bits to the
high bits. It doesn't matter much, but looking at the original paper, and
googling around for other Simple-8b implementations, that's how it's
usually done.
Per Coverity, and Tom Lane's report off-list. M src/backend/lib/integerset.c
M src/test/modules/test_integerset/test_integerset.c
Align timestamps in pg_regress output
commit : 148cf5f462e53f374a2085b2fa8dcde944539b03
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 25 Mar 2019 10:00:11 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 25 Mar 2019 10:00:11 +0100 This way the timestamps line up in a mix of "ok" and "FAILED" output.
Author: Christoph Berg <christoph.berg@credativ.de>
Discussion: https://www.postgresql.org/message-id/20190321115059.GF2687%40msg.df7cb.de M src/test/regress/pg_regress.c
Add macro to cast away volatile without allowing changes to underlying type
commit : 481018f2804065cb5ed1cde75b7c0596aeef959a
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 25 Mar 2019 09:35:29 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 25 Mar 2019 09:35:29 +0100 This adds unvolatize(), which works just like unconstify() but for volatile.
Discussion: https://www.postgresql.org/message-id/flat/7a5cbea7-b8df-e910-0f10-04014bcad701%402ndquadrant.com M src/backend/postmaster/pgstat.c
M src/backend/storage/ipc/pmsignal.c
M src/include/c.h
Initialize structure at declaration
commit : 572e3e6634e55accf95e2bcfb1340019c86a21dc
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 25 Mar 2019 09:35:22 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 25 Mar 2019 09:35:22 +0100 Avoids extra memset call and cast.
Discussion: https://www.postgresql.org/message-id/flat/7a5cbea7-b8df-e910-0f10-04014bcad701%402ndquadrant.com M contrib/dblink/dblink.c
tableam: Add and use table_fetch_row_version().
commit : 9a8ee1dc650be623c32b1df103254847be974d01
author : Andres Freund <andres@anarazel.de>
date : Mon, 25 Mar 2019 00:13:42 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 25 Mar 2019 00:13:42 -0700 This is essentially the tableam version of heapam_fetch(),
i.e. fetching a tuple identified by a tid, performing visibility
checks.
Note that this different from table_index_fetch_tuple(), which is for
index lookups. It therefore has to handle a tid pointing to an earlier
version of a tuple if the AM uses an optimization like heap's HOT. Add
comments to that end.
This commit removes the stats_relation argument from heap_fetch, as
it's been unused for a long time.
Author: Andres Freund
Reviewed-By: Haribabu Kommi
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/table/tableamapi.c
M src/backend/commands/trigger.c
M src/backend/executor/execMain.c
M src/backend/executor/nodeModifyTable.c
M src/backend/executor/nodeTidscan.c
M src/include/access/heapam.h
M src/include/access/tableam.h
Add ORDER BY to regression test case
commit : c77e12208cd8540a209cc698373a3cfba8802639
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 25 Mar 2019 08:15:38 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 25 Mar 2019 08:15:38 +0100 Apparently, the output order is different on different endianness, per
build farm member snapper. M src/test/regress/expected/collate.icu.utf8.out
M src/test/regress/sql/collate.icu.utf8.sql
tableam: Use in CREATE TABLE AS and CREATE MATERIALIZED VIEW.
commit : 919e48b943014b1d4ab5d83e48dbc9f8e87e7be4
author : Andres Freund <andres@anarazel.de>
date : Sun, 24 Mar 2019 18:55:34 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 24 Mar 2019 18:55:34 -0700 Previously those directly performed a heap_insert(). Use
table_insert() instead. The input slot of those routines is not of
the target relation - we could fix that by copying if necessary, but
that'd not be beneficial for performance. As those codepaths don't
access any AM specific tuple fields (say xmin/xmax), there's no need
to use an AM specific slot.
Author: Andres Freund
Reviewed-By: Haribabu Kommi
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de M src/backend/commands/createas.c
M src/backend/commands/matview.c
Un-hide most cascaded-drop details in regression test results.
commit : 940311e4bb32a5fe99155052e41179c88b5d48af
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Mar 2019 19:15:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Mar 2019 19:15:37 -0400 Now that the ordering of DROP messages ought to be stable everywhere,
we should not need these kluges of hiding DETAIL output just to avoid
unstable ordering. Hiding it's not great for test coverage, so
let's undo that where possible.
In a small number of places, it's necessary to leave it in, for
example because the output might include a variable pg_temp_nnn
schema name. I also left things alone in places where the details
would depend on other regression test scripts, e.g. plpython_drop.sql.
Perhaps buildfarm experience will show this to be a bad idea,
but if so I'd like to know why.
Discussion: https://postgr.es/m/E1h6eep-0001Mw-Vd@gemulon.postgresql.org M src/test/regress/expected/alter_generic.out
M src/test/regress/expected/collate.out
M src/test/regress/expected/create_function_3.out
M src/test/regress/expected/create_index.out
M src/test/regress/expected/create_view.out
M src/test/regress/expected/dependency.out
M src/test/regress/expected/event_trigger.out
M src/test/regress/expected/float4-misrounded-input.out
M src/test/regress/expected/float4.out
M src/test/regress/expected/float8.out
M src/test/regress/expected/foreign_data.out
M src/test/regress/expected/foreign_key.out
M src/test/regress/expected/object_address.out
M src/test/regress/expected/partition_prune.out
M src/test/regress/expected/privileges.out
M src/test/regress/expected/rolenames.out
M src/test/regress/expected/rowsecurity.out
M src/test/regress/expected/rules.out
M src/test/regress/expected/stats_ext.out
M src/test/regress/expected/truncate.out
M src/test/regress/sql/alter_generic.sql
M src/test/regress/sql/collate.sql
M src/test/regress/sql/create_function_3.sql
M src/test/regress/sql/create_index.sql
M src/test/regress/sql/create_view.sql
M src/test/regress/sql/dependency.sql
M src/test/regress/sql/event_trigger.sql
M src/test/regress/sql/float4.sql
M src/test/regress/sql/float8.sql
M src/test/regress/sql/foreign_data.sql
M src/test/regress/sql/foreign_key.sql
M src/test/regress/sql/object_address.sql
M src/test/regress/sql/partition_prune.sql
M src/test/regress/sql/privileges.sql
M src/test/regress/sql/rolenames.sql
M src/test/regress/sql/rowsecurity.sql
M src/test/regress/sql/rules.sql
M src/test/regress/sql/stats_ext.sql
M src/test/regress/sql/truncate.sql
Sort dependent objects before reporting them in DROP ROLE.
commit : af6550d34466b3093edda54a0cc5a6f220d321b7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Mar 2019 18:17:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Mar 2019 18:17:41 -0400 Commit 8aa9dd74b didn't quite finish the job in this area after all,
because DROP ROLE has a code path distinct from DROP OWNED BY, and
it was still reporting dependent objects in whatever order the index
scan returned them in.
Buildfarm experience shows that index ordering of equal-keyed objects is
significantly less stable than before in the wake of using heap TIDs as
tie-breakers. So if we try to hide the unstable ordering by suppressing
DETAIL reports, we're just going to end up having to do that for every
DROP that reports multiple objects. That's not great from a coverage
or problem-detection standpoint, and it's something we'll inevitably
forget in future patches, leading to more iterations of fixing-an-
unstable-result. So let's just bite the bullet and sort here too.
Discussion: https://postgr.es/m/E1h6eep-0001Mw-Vd@gemulon.postgresql.org M src/backend/catalog/pg_shdepend.c
M src/test/regress/expected/dependency.out
Remove dead code from nbtsplitloc.c.
commit : 59ab3be9e4d3e3cdf03bada2f6fb3d71a1e42908
author : Peter Geoghegan <pg@bowt.ie>
date : Sun, 24 Mar 2019 12:28:58 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Sun, 24 Mar 2019 12:28:58 -0700 It doesn't make sense to consider the possibility that there will only
be one candidate split point when choosing among split points to find
the split with the lowest penalty. This is a vestige of an earlier
version of the patch that became commit fab25024.
Issue spotted while rereviewing coverage of the nbtree patch series
using gcov. M src/backend/access/nbtree/nbtsplitloc.c
Avoid double-free in vacuumlo error path.
commit : bd9396a0b2d42497f1196af74b327e00cb6af435
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Mar 2019 15:13:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 24 Mar 2019 15:13:20 -0400 The code would do "PQclear(res)" twice if lo_unlink failed, evidently
due to careless thinking about how far out a "break" would break.
Remove the extra PQclear and adjust the loop logic so that we'll fall
out of both levels of loop after an error, as was clearly the intent.
Spotted by Coverity. I have no idea why it took this long to notice,
since the bug has been there since commit 67ccbb080. Accordingly,
back-patch to all supported branches. M contrib/vacuumlo/vacuumlo.c
Make current_logfiles use permissions assigned to files in data directory
commit : 276d2e6c2d8141f194a26da03b5b79375eb7041b
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 24 Mar 2019 21:00:35 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 24 Mar 2019 21:00:35 +0900 Since its introduction in 19dc233c, current_logfiles has been assigned
the same permissions as a log file, which can be enforced with
log_file_mode. This setup can lead to incompatibility problems with
group access permissions as current_logfiles is not located in the log
directory, but at the root of the data folder. Hence, if group
permissions are used but log_file_mode is more restrictive, a backup
with a user in the group having read access could fail even if the log
directory is located outside of the data folder.
Per discussion with the folks mentioned below, we have concluded that
current_logfiles should not be treated as a log file as it only stores
metadata related to log files, and that it should use the same
permissions as all other files in the data directory. This solution has
the merit to be simple and fixes all the interaction problems between
group access and log_file_mode.
Author: Haribabu Kommi
Reviewed-by: Stephen Frost, Robert Haas, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/CAJrrPGcEotF1P7AWoeQyD3Pqr-0xkQg_Herv98DjbaMj+naozw@mail.gmail.com
Backpatch-through: 11, where group access has been added. M src/backend/postmaster/syslogger.c
Transaction chaining
commit : 280a408b48d5ee42969f981bceb9e9426c3a344c
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 24 Mar 2019 10:33:14 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 24 Mar 2019 10:33:14 +0100 Add command variants COMMIT AND CHAIN and ROLLBACK AND CHAIN, which
start new transactions with the same transaction characteristics as the
just finished one, per SQL standard.
Support for transaction chaining in PL/pgSQL is also added. This
functionality is especially useful when running COMMIT in a loop in
PL/pgSQL.
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
Discussion: https://www.postgresql.org/message-id/flat/28536681-324b-10dc-ade8-ab46f7645a5a@2ndquadrant.com M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/ref/abort.sgml
M doc/src/sgml/ref/commit.sgml
M doc/src/sgml/ref/end.sgml
M doc/src/sgml/ref/rollback.sgml
M doc/src/sgml/spi.sgml
M src/backend/access/transam/xact.c
M src/backend/catalog/sql_features.txt
M src/backend/executor/spi.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/parser/gram.y
M src/backend/tcop/utility.c
M src/bin/psql/tab-complete.c
M src/include/access/xact.h
M src/include/executor/spi.h
M src/include/nodes/parsenodes.h
M src/pl/plpgsql/src/expected/plpgsql_transaction.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/pl_funcs.c
M src/pl/plpgsql/src/pl_gram.y
M src/pl/plpgsql/src/pl_unreserved_kwlist.h
M src/pl/plpgsql/src/plpgsql.h
M src/pl/plpgsql/src/sql/plpgsql_transaction.sql
M src/test/regress/expected/transactions.out
M src/test/regress/sql/transactions.sql
Remove spurious return.
commit : b2db277057a375ccbcc98cc3bbce8ce5b4d788ea
author : Andres Freund <andres@anarazel.de>
date : Sat, 23 Mar 2019 21:09:39 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sat, 23 Mar 2019 21:09:39 -0700 Per buildfarm member anole.
Author: Andres Freund M src/include/access/tableam.h
tableam: Add tuple_{insert, delete, update, lock} and use.
commit : 5db6df0c0117ff2a4e0cd87594d2db408cd5022f
author : Andres Freund <andres@anarazel.de>
date : Sat, 23 Mar 2019 19:55:57 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sat, 23 Mar 2019 19:55:57 -0700 This adds new, required, table AM callbacks for insert/delete/update
and lock_tuple. To be able to reasonably use those, the EvalPlanQual
mechanism had to be adapted, moving more logic into the AM.
Previously both delete/update/lock call-sites and the EPQ mechanism had
to have awareness of the specific tuple format to be able to fetch the
latest version of a tuple. Obviously that needs to be abstracted
away. To do so, move the logic that find the latest row version into
the AM. lock_tuple has a new flag argument,
TUPLE_LOCK_FLAG_FIND_LAST_VERSION, that forces it to lock the last
version, rather than the current one. It'd have been possible to do
so via a separate callback as well, but finding the last version
usually also necessitates locking the newest version, making it
sensible to combine the two. This replaces the previous use of
EvalPlanQualFetch(). Additionally HeapTupleUpdated, which previously
signaled either a concurrent update or delete, is now split into two,
to avoid callers needing AM specific knowledge to differentiate.
The move of finding the latest row version into tuple_lock means that
encountering a row concurrently moved into another partition will now
raise an error about "tuple to be locked" rather than "tuple to be
updated/deleted" - which is accurate, as that always happens when
locking rows. While possible slightly less helpful for users, it seems
like an acceptable trade-off.
As part of this commit HTSU_Result has been renamed to TM_Result, and
its members been expanded to differentiated between updating and
deleting. HeapUpdateFailureData has been renamed to TM_FailureData.
The interface to speculative insertion is changed so nodeModifyTable.c
does not have to set the speculative token itself anymore. Instead
there's a version of tuple_insert, tuple_insert_speculative, that
performs the speculative insertion (without requiring a flag to signal
that fact), and the speculative insertion is either made permanent
with table_complete_speculative(succeeded = true) or aborted with
succeeded = false).
Note that multi_insert is not yet routed through tableam, nor is
COPY. Changing multi_insert requires changes to copy.c that are large
enough to better be done separately.
Similarly, although simpler, CREATE TABLE AS and CREATE MATERIALIZED
VIEW are also only going to be adjusted in a later commit.
Author: Andres Freund and Haribabu Kommi
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20190313003903.nwvrxi7rw3ywhdel@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql M contrib/pgrowlocks/pgrowlocks.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/heap/heapam_visibility.c
M src/backend/access/heap/tuptoaster.c
M src/backend/access/table/tableam.c
M src/backend/access/table/tableamapi.c
M src/backend/commands/copy.c
M src/backend/commands/trigger.c
M src/backend/executor/execIndexing.c
M src/backend/executor/execMain.c
M src/backend/executor/execReplication.c
M src/backend/executor/nodeLockRows.c
M src/backend/executor/nodeModifyTable.c
M src/backend/executor/nodeTidscan.c
M src/include/access/heapam.h
M src/include/access/tableam.h
M src/include/executor/executor.h
M src/include/utils/snapshot.h
M src/test/isolation/expected/partition-key-update-1.out
M src/tools/pgindent/typedefs.list
Remove inadequate check for duplicate “xml” PI.
commit : f778e537a0d02d5e05016da3e6f4068914101dee
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 17:40:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 17:40:19 -0400 I failed to think about PIs starting with "xml". We don't really
need this check at all, so just take it out. Oversight in
commit 8d1dadb25 et al. M src/backend/utils/adt/xml.c
Ensure xmloption = content while restoring pg_dump output.
commit : 4870dce37fab7ed308cee9856bec4d4c8c7590b3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 16:51:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 16:51:25 -0400 In combination with the previous commit, this ensures that valid XML
data can always be dumped and reloaded, whether it is "document"
or "content".
Discussion: https://postgr.es/m/CAN-V+g-6JqUQEQZ55Q3toXEN6d5Ez5uvzL4VR+8KtvJKj31taw@mail.gmail.com M src/bin/pg_dump/pg_backup_archiver.c
Accept XML documents when xmloption = content, as required by SQL:2006+.
commit : 8d1dadb25bb522e09af7f141e9d78db5805d868c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 16:24:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 16:24:30 -0400 Previously we were using the SQL:2003 definition, which doesn't allow
this, but that creates a serious dump/restore gotcha: there is no
setting of xmloption that will allow all valid XML data. Hence,
switch to the 2006 definition.
Since libxml doesn't accept <!DOCTYPE> directives in the mode we
use for CONTENT parsing, the implementation is to detect <!DOCTYPE>
in the input and switch to DOCUMENT parsing mode. This should not
cost much, because <!DOCTYPE> should be close to the front of the
input if it's there at all. It's possible that this causes the
error messages for malformed input to be slightly different than
they were before, if said input includes <!DOCTYPE>; but that does
not seem like a big problem.
In passing, buy back a few cycles in parsing of large XML documents
by not doing strlen() of the whole input in parse_xml_decl().
Back-patch because dump/restore failures are not nice. This change
shouldn't break any cases that worked before, so it seems safe to
back-patch.
Chapman Flack (revised a bit by me)
Discussion: https://postgr.es/m/CAN-V+g-6JqUQEQZ55Q3toXEN6d5Ez5uvzL4VR+8KtvJKj31taw@mail.gmail.com M doc/src/sgml/datatype.sgml
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_1.out
M src/test/regress/expected/xml_2.out
M src/test/regress/sql/xml.sql
Suppress DETAIL output from an event_trigger test.
commit : 05f110cc0b83d9dc174f72cf96798299eb3e7f67
author : Peter Geoghegan <pg@bowt.ie>
date : Sat, 23 Mar 2019 13:49:53 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Sat, 23 Mar 2019 13:49:53 -0700 Suppress 3 lines of unstable DETAIL output from a DROP ROLE statement in
event_trigger.sql. This is further cleanup for commit dd299df8.
Note that the event_trigger test instability issue is very similar to
the recently suppressed foreign_data test instability issue. Both
issues involve DETAIL output for a DROP ROLE statement that needed to be
changed as part of dd299df8.
Per buildfarm member macaque. M src/test/regress/expected/event_trigger.out
M src/test/regress/sql/event_trigger.sql
Add nbtree high key “continuescan” optimization.
commit : 29b64d1de7c77ffb5cb10696693e6ed8a6fc481c
author : Peter Geoghegan <pg@bowt.ie>
date : Sat, 23 Mar 2019 11:01:53 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Sat, 23 Mar 2019 11:01:53 -0700 Teach nbtree forward index scans to check the high key before moving to
the right sibling page in the hope of finding that it isn't actually
necessary to do so. The new check may indicate that the scan definitely
cannot find matching tuples to the right, ending the scan immediately.
We already opportunistically force a similar "continuescan orientated"
key check of the final non-pivot tuple when it's clear that it cannot be
returned to the scan due to being dead-to-all. The new high key check
is complementary.
The new approach for forward scans is more effective than checking the
final non-pivot tuple, especially with composite indexes and non-unique
indexes. The improvements to the logic for picking a split point added
by commit fab25024 make it likely that relatively dissimilar high keys
will appear on a page. A distinguishing key value that can only appear
on non-pivot tuples on the right sibling page will often be present in
leaf page high keys.
Since forcing the final item to be key checked no longer makes any
difference in the case of forward scans, the existing extra key check is
now only used for backwards scans. Backward scans continue to
opportunistically check the final non-pivot tuple, which is actually the
first non-pivot tuple on the page (not the last).
Note that even pg_upgrade'd v3 indexes make use of this optimization.
Author: Peter Geoghegan, Heikki Linnakangas
Reviewed-By: Heikki Linnakangas
Discussion: https://postgr.es/m/CAH2-WzkOmUduME31QnuTFpimejuQoiZ-HOf0pOWeFZNhTMctvA@mail.gmail.com M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtutils.c
M src/include/access/nbtree.h
Improve format of code and some error messages in pg_checksums
commit : 4ba96d1b82d694fead0ac709f9429cbb7ea89cb0
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 23 Mar 2019 21:56:43 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 23 Mar 2019 21:56:43 +0900 This makes the code more consistent with the surroundings.
Author: Fabrízio de Royes Mello
Discussion: https://postgr.es/m/CAFcNs+pXb_35r5feMU3-dWsWxXU=Yjq+spUsthFyGFbT0QcaKg@mail.gmail.com M src/bin/pg_checksums/pg_checksums.c
Add unreachable “break” to satisfy -Wimplicit-fallthrough.
commit : fb50d3f03fe6876b878d636a312c2ccc1f4f99af
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 01:32:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 23 Mar 2019 01:32:58 -0400 gcc is a bit pickier about this than perhaps it should be.
Discussion: https://postgr.es/m/E1h6zzT-0003ft-DD@gemulon.postgresql.org M src/backend/parser/parse_func.c
Expand EPQ tests for UPDATEs and DELETEs
commit : cdcffe2263215eef9078ce97e6c9adece8ed1910
author : Andres Freund <andres@anarazel.de>
date : Fri, 22 Mar 2019 19:55:23 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 22 Mar 2019 19:55:23 -0700 Previously there was basically no coverage for UPDATEs encountering
deleted rows, and no coverage for DELETE having to perform EPQ. That's
problematic for an upcoming commit in which EPQ is tought to integrate
with tableams. Also, there was no test for UPDATE to encounter a row
UPDATEd into another partition.
Author: Andres Freund M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/expected/partition-key-update-1.out
M src/test/isolation/specs/eval-plan-qual.spec
M src/test/isolation/specs/partition-key-update-1.spec
Add option -N/–no-sync to pg_checksums
commit : e0090c86900877bf0911c53dcf4a30bc81d03047
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 23 Mar 2019 08:37:36 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 23 Mar 2019 08:37:36 +0900 This is an option consistent with what pg_dump, pg_rewind and
pg_basebackup provide which is useful for leveraging the I/O effort when
testing things, not to be used in a production environment.
Author: Michael Paquier
Reviewed-by: Michael Banck, Fabien Coelho, Sergei Kornilov
Discussion: https://postgr.es/m/20181221201616.GD4974@nighthawk.caipicrew.dd-dns.de M doc/src/sgml/ref/pg_checksums.sgml
M src/bin/pg_checksums/pg_checksums.c
M src/bin/pg_checksums/t/002_actions.pl
Revert “Add gitignore entries for jsonpath_gram.h”
commit : 7b084b38310cfe9c8b58cc615a81df625c771f5d
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 23 Mar 2019 00:19:34 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 23 Mar 2019 00:19:34 +0100 This reverts commit 4e274a043fc8310ce1148190ef674beca06e990c.
These files aren't actually built anymore since 550b9d26f. M src/backend/utils/adt/.gitignore
M src/include/utils/.gitignore
Add options to enable and disable checksums in pg_checksums
commit : ed308d78379008b2cebca30a986f97f992ee6122
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 23 Mar 2019 08:12:55 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 23 Mar 2019 08:12:55 +0900 An offline cluster can now work with more modes in pg_checksums:
- --enable enables checksums in a cluster, updating all blocks with a
correct checksum, and updating the control file at the end.
- --disable disables checksums in a cluster, updating only the control
file.
- --check is an extra option able to verify checksums for a cluster, and
the default used if no mode is specified.
When running --enable or --disable, the data folder gets fsync'd for
durability, and then it is followed by a control file update and flush
to keep the operation consistent should the tool be interrupted, killed
or the host unplugged. If no mode is specified in the options, then
--check is used for compatibility with older versions of pg_checksums
(named pg_verify_checksums in v11 where it was introduced).
Author: Michael Banck, Michael Paquier
Reviewed-by: Fabien Coelho, Magnus Hagander, Sergei Kornilov
Discussion: https://postgr.es/m/20181221201616.GD4974@nighthawk.caipicrew.dd-dns.de M doc/src/sgml/ref/pg_checksums.sgml
M src/bin/pg_checksums/pg_checksums.c
M src/bin/pg_checksums/t/002_actions.pl
M src/tools/pgindent/typedefs.list
Make subscription collation test work independent of locale
commit : 87914e708aabb7e2cd9045fa95b4fed99ca458ec
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 22 Mar 2019 23:33:31 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 22 Mar 2019 23:33:31 +0100 We need to set the database to UTF8 encoding so that the test can use
Unicode escapes. M src/test/subscription/t/012_collation.pl
Add gitignore entries for jsonpath_gram.h
commit : 4e274a043fc8310ce1148190ef674beca06e990c
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 22 Mar 2019 23:19:30 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 22 Mar 2019 23:19:30 +0100 M src/backend/utils/adt/.gitignore
M src/include/utils/.gitignore
Rearrange make_partitionedrel_pruneinfo to avoid work when we can’t prune.
commit : 734308a220729e4ececa3758bdcae39a335d55ea
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Mar 2019 14:56:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Mar 2019 14:56:05 -0400 Postpone most of the effort of constructing PartitionedRelPruneInfos
until after we have found out whether run-time pruning is needed at all.
This costs very little duplicated effort (basically just an extra
find_base_rel() call per partition) and saves quite a bit when we
can't do run-time pruning.
Also, merge the first loop (for building relid_subpart_map) into
the second loop, since we don't need the map to be valid during
that loop.
Amit Langote
Discussion: https://postgr.es/m/9d7c5112-cb99-6a47-d3be-cf1ee6862a1d@lab.ntt.co.jp M src/backend/partitioning/partprune.c
Go back to suppressing foreign_data DETAIL test output.
commit : 09963cedced7ffb98a06298cc16305767fd2b4dd
author : Peter Geoghegan <pg@bowt.ie>
date : Fri, 22 Mar 2019 11:34:28 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Fri, 22 Mar 2019 11:34:28 -0700 This is almost a straight revert of commit fff518d, which itself was a
revert of 7d3bf73ac.
It turns out that commit 8aa9dd74, which sorted dependent objects before
deletion in DROP OWNED BY, was not sufficient to make all remaining
unstable DETAIL output stable. Unstable DETAIL output from DROP ROLE
was not affected, because that happens to use a different code path. It
doesn't seem worthwhile to fix the other code path at this time.
Discussion: https://postgr.es/m/6226.1553274783@sss.pgh.pa.us M src/test/regress/expected/foreign_data.out
M src/test/regress/sql/foreign_data.sql
Don’t copy PartitionBoundInfo in set_relation_partition_info.
commit : c8151e642368599dc77c4448e6bdc34cc8810475
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Mar 2019 14:16:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 22 Mar 2019 14:16:50 -0400 I (tgl) remain dubious that it's a good idea for PartitionDirectory
to hold a pin on a relcache entry throughout planning, rather than
copying the data or using some kind of refcount scheme. However, it's
certainly the responsibility of the PartitionDirectory code to ensure
that what it's handing back is a stable data structure, not that of
its caller. So this is a pretty clear oversight in commit 898e5e329,
and one that can cost a lot of performance when there are many
partitions.
Amit Langote (extracted from a much larger patch set)
Discussion: https://postgr.es/m/CA+TgmoY3bRmGB6-DUnoVy5fJoreiBJ43rwMrQRCdPXuKt4Ykaw@mail.gmail.com
Discussion: https://postgr.es/m/9d7c5112-cb99-6a47-d3be-cf1ee6862a1d@lab.ntt.co.jp M src/backend/optimizer/util/plancat.c
Fix yet more portability bugs in integerset and its tests.
commit : b5fd4972a3bc758c0b8e8c9cd4aa32bacdeb6605
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 17:59:19 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 17:59:19 +0200 There were more large constants that needed UINT64CONST. And one variable
was declared as "int", when it needed to be uint64. These bugs were only
visible on 32-bit systems; clearly I should've tested on one, given that
this code does a lot of work with 64-bit integers.
Also, in the test "huge distances" test, the code created some values with
random distances between them, but the test logic didn't take into account
the possibility that the random distance was exactly 1. That never actually
happens with the seed we're using, but let's be tidy. M src/backend/lib/integerset.c
M src/test/modules/test_integerset/test_integerset.c
Fix ICU tests for older ICU versions
commit : 638db07814f389e739b2cfde01b592aa9150b1be
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 22 Mar 2019 14:40:56 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 22 Mar 2019 14:40:56 +0100 Change the tests to use old-style ICU locale specifications so that
they can run on older ICU versions. M src/test/regress/expected/collate.icu.utf8.out
M src/test/regress/sql/collate.icu.utf8.sql
More portability fixes for integerset tests.
commit : c477c68c8f660550219c69fac2ab41beb86d7f45
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 14:57:35 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 14:57:35 +0200 Use UINT64CONST for large constants. M src/test/modules/test_integerset/test_integerset.c
Make printf format strings in test_integerset portable.
commit : 32f8ddf7e1c8b24382f98c14f6b588cd7e17418c
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 14:42:33 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 14:42:33 +0200 Use UINT64_FORMAT for printing uint64s. M src/test/modules/test_integerset/test_integerset.c
Make the integerset test more verbose.
commit : 608c5f4347acefdbb2663b9fb6deab079b4b3c8b
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 14:32:53 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 14:32:53 +0200 Buildfarm member 'woodlouse' failed one of the tests, and I'm not sure
which test failed. Better to print the names of the tests, so that it
will appear in the regression.diffs on failure. M src/test/modules/test_integerset/expected/test_integerset.out
M src/test/modules/test_integerset/sql/test_integerset.sql
Fix bug in the GiST vacuum’s 2nd stage.
commit : d1b9ee4e44062cc540d8e406f49b160326d58a84
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 14:11:46 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 14:11:46 +0200 We mustn't assume that the IndexVacuumInfo pointer passed to bulkdelete()
stage is still valid in the vacuumcleanup() stage.
Per very pink buildfarm. M src/backend/access/gist/gistvacuum.c
Delete empty pages during GiST VACUUM.
commit : 7df159a620b760e289f1795b13542ed1b3e13b87
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 13:21:20 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 13:21:20 +0200 To do this, we scan GiST two times. In the first pass we make note of
empty leaf pages and internal pages. At second pass we scan through
internal pages, looking for downlinks to the empty pages.
Deleting internal pages is still not supported, like in nbtree, the last
child of an internal page is never deleted. That means that if you have a
workload where new keys are always inserted to different area than where
old keys are removed, the index will still grow without bound. But the rate
of growth will be an order of magnitude slower than before.
Author: Andrey Borodin
Discussion: https://www.postgresql.org/message-id/B1E4DF12-6CD3-4706-BDBD-BF3283328F60@yandex-team.ru M src/backend/access/gist/README
M src/backend/access/gist/gist.c
M src/backend/access/gist/gistutil.c
M src/backend/access/gist/gistvacuum.c
M src/backend/access/gist/gistxlog.c
M src/backend/access/rmgrdesc/gistdesc.c
M src/include/access/gist.h
M src/include/access/gist_private.h
M src/include/access/gistxlog.h
M src/test/regress/expected/gist.out
M src/test/regress/sql/gist.sql
Add IntegerSet, to hold large sets of 64-bit ints efficiently.
commit : df816f6ad532ad685a3897869a2e64d3a53fe312
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 13:21:19 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 22 Mar 2019 13:21:19 +0200 The set is implemented as a B-tree, with a compact representation at leaf
items, using Simple-8b algorithm, so that clusters of nearby values use
less memory.
The IntegerSet isn't used for anything yet, aside from the test code, but
we have two patches in the works that would benefit from this: A patch to
allow GiST vacuum to delete empty pages, and a patch to reduce heap
VACUUM's memory usage, by storing the list of dead TIDs more efficiently
and lifting the 1 GB limit on its size.
This includes a unit test module, in src/test/modules/test_integerset.
It can be used to verify correctness, as a regression test, but if you run
it manully, it can also print memory usage and execution time of some of
the tests.
Author: Heikki Linnakangas, Andrey Borodin
Reviewed-by: Julien Rouhaud
Discussion: https://www.postgresql.org/message-id/b5e82599-1966-5783-733c-1a947ddb729f@iki.fi M src/backend/lib/Makefile
M src/backend/lib/README
A src/backend/lib/integerset.c
A src/include/lib/integerset.h
M src/test/modules/Makefile
A src/test/modules/test_integerset/.gitignore
A src/test/modules/test_integerset/Makefile
A src/test/modules/test_integerset/README
A src/test/modules/test_integerset/expected/test_integerset.out
A src/test/modules/test_integerset/sql/test_integerset.sql
A src/test/modules/test_integerset/test_integerset–1.0.sql
A src/test/modules/test_integerset/test_integerset.c
A src/test/modules/test_integerset/test_integerset.control
Collations with nondeterministic comparison
commit : 5e1963fb764e9cc092e0f7b58b28985c311431d9
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 22 Mar 2019 12:09:32 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 22 Mar 2019 12:09:32 +0100 This adds a flag "deterministic" to collations. If that is false,
such a collation disables various optimizations that assume that
strings are equal only if they are byte-wise equal. That then allows
use cases such as case-insensitive or accent-insensitive comparisons
or handling of strings with different Unicode normal forms.
This functionality is only supported with the ICU provider. At least
glibc doesn't appear to have any locales that work in a
nondeterministic way, so it's not worth supporting this for the libc
provider.
The term "deterministic comparison" in this context is from Unicode
Technical Standard #10
(https://unicode.org/reports/tr10/#Deterministic_Comparison).
This patch makes changes in three areas:
- CREATE COLLATION DDL changes and system catalog changes to support
this new flag.
- Many executor nodes and auxiliary code are extended to track
collations. Previously, this code would just throw away collation
information, because the eventually-called user-defined functions
didn't use it since they only cared about equality, which didn't
need collation information.
- String data type functions that do equality comparisons and hashing
are changed to take the (non-)deterministic flag into account. For
comparison, this just means skipping various shortcuts and tie
breakers that use byte-wise comparison. For hashing, we first need
to convert the input string to a canonical "sort key" using the ICU
analogue of strxfrm().
Reviewed-by: Daniel Verite <daniel@manitou-mail.org>
Reviewed-by: Peter Geoghegan <pg@bowt.ie>
Discussion: https://www.postgresql.org/message-id/flat/1ccc668f-4cbc-0bef-af67-450b47cdfee7@2ndquadrant.com M contrib/bloom/bloom.h
M contrib/bloom/blutils.c
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/charset.sgml
M doc/src/sgml/citext.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/ref/create_collation.sgml
M src/backend/access/hash/hashfunc.c
M src/backend/access/spgist/spgtextproc.c
M src/backend/catalog/pg_collation.c
M src/backend/commands/collationcmds.c
M src/backend/commands/extension.c
M src/backend/executor/execExpr.c
M src/backend/executor/execGrouping.c
M src/backend/executor/execPartition.c
M src/backend/executor/execReplication.c
M src/backend/executor/nodeAgg.c
M src/backend/executor/nodeGroup.c
M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c
M src/backend/executor/nodeRecursiveunion.c
M src/backend/executor/nodeSetOp.c
M src/backend/executor/nodeSubplan.c
M src/backend/executor/nodeUnique.c
M src/backend/executor/nodeWindowAgg.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/util/tlist.c
M src/backend/partitioning/partbounds.c
M src/backend/partitioning/partprune.c
M src/backend/regex/regc_pg_locale.c
M src/backend/utils/adt/arrayfuncs.c
M src/backend/utils/adt/like.c
M src/backend/utils/adt/like_support.c
M src/backend/utils/adt/name.c
M src/backend/utils/adt/orderedsetaggs.c
M src/backend/utils/adt/pg_locale.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/adt/varchar.c
M src/backend/utils/adt/varlena.c
M src/backend/utils/cache/catcache.c
M src/backend/utils/cache/lsyscache.c
M src/bin/initdb/initdb.c
M src/bin/pg_dump/pg_dump.c
M src/bin/psql/describe.c
M src/include/catalog/catversion.h
M src/include/catalog/pg_collation.h
M src/include/executor/executor.h
M src/include/executor/hashjoin.h
M src/include/executor/nodeHash.h
M src/include/nodes/execnodes.h
M src/include/nodes/plannodes.h
M src/include/optimizer/planmain.h
M src/include/optimizer/tlist.h
M src/include/partitioning/partbounds.h
M src/include/utils/lsyscache.h
M src/include/utils/pg_locale.h
M src/test/regress/expected/collate.icu.utf8.out
M src/test/regress/expected/collate.linux.utf8.out
M src/test/regress/expected/collate.out
M src/test/regress/expected/subselect.out
M src/test/regress/sql/collate.icu.utf8.sql
M src/test/regress/sql/collate.linux.utf8.sql
M src/test/regress/sql/collate.sql
M src/test/regress/sql/subselect.sql
M src/test/subscription/Makefile
A src/test/subscription/t/012_collation.pl
Fix crash with pg_partition_root
commit : 2ab6d28d233af17987ea323e3235b2bda89b4f2e
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 22 Mar 2019 17:27:38 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 22 Mar 2019 17:27:38 +0900 Trying to call the function with the top-most parent of a partition tree
was leading to a crash. In this case the correct result is to return
the top-most parent itself.
Reported-by: Álvaro Herrera
Author: Michael Paquier
Reviewed-by: Amit Langote
Discussion: https://postgr.es/m/20190322032612.GA323@alvherre.pgsql M src/backend/utils/adt/partitionfuncs.c
M src/test/regress/expected/partition_info.out
M src/test/regress/sql/partition_info.sql
Revert “Suppress DETAIL output from a foreign_data test.”
commit : fff518d051285bc47e2694a349d410e01972730b
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 21 Mar 2019 15:33:13 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 21 Mar 2019 15:33:13 -0700 This should be superseded by commit 8aa9dd74. M src/test/regress/expected/foreign_data.out
M src/test/regress/sql/foreign_data.sql
Catversion bump announced in previous commit but forgotten
commit : 03ae9d59bd5f5ef9a1cb387568e5cbf12b9c7b10
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 21 Mar 2019 18:43:24 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 21 Mar 2019 18:43:24 -0300 M src/include/catalog/catversion.h
Fix dependency recording bug for partitioned PKs
commit : 7e7c57bbb2ebed7e8acbd2e62fadca5a5fe5df5f
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 21 Mar 2019 18:34:29 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 21 Mar 2019 18:34:29 -0300 When DefineIndex recurses to create constraints on partitions, it needs
to use the value returned by index_constraint_create to set up partition
dependencies. However, in the course of fixing the DEPENDENCY_INTERNAL_AUTO
mess, commit 1d92a0c9f7dd introduced some code to that function that
clobbered the return value, causing the recorded OID to be of the wrong
object. Close examination of pg_depend after creating the tables leads
to indescribable objects :-( My sin (in commit bdc3d7fa2376, while
preparing for DDL deparsing in event triggers) was to use a variable
name for the return value that's typically used for throwaway objects in
dependency-setting calls ("referenced"). Fix by changing the variable
names to match extended practice (the return value is "myself" rather
than "referenced".)
The pg_upgrade test notices the problem (in an indirect way: the pg_dump
outputs are in different order), but only if you create the objects in a
specific way that wasn't being used in the existing tests. Add a stanza
to leave some objects around that shows the bug.
Catversion bump because preexisting databases might have bogus pg_depend
entries.
Discussion: https://postgr.es/m/20190318204235.GA30360@alvherre.pgsql M src/backend/catalog/index.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql
Improve error reporting for DROP FUNCTION/PROCEDURE/AGGREGATE/ROUTINE.
commit : bfb456c1b9656d5b717b84d833f62cf712b21726
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Mar 2019 11:51:55 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 21 Mar 2019 11:51:55 -0400 These commands allow the argument type list to be omitted if there is
just one object that matches by name. However, if that syntax was
used with DROP IF EXISTS and there was more than one match, you got
a "function ... does not exist, skipping" notice message rather than a
truthful complaint about the ambiguity. This was basically due to
poor factorization and a rats-nest of logic, so refactor the relevant
lookup code to make it cleaner.
Note that this amounts to narrowing the scope of which sorts of
error conditions IF EXISTS will bypass. Per discussion, we only
intend it to skip no-such-object cases, not multiple-possible-matches
cases.
Per bug #15572 from Ash Marath. Although this definitely seems like
a bug, it's not clear that people would thank us for changing the
behavior in minor releases, so no back-patch.
David Rowley, reviewed by Julien Rouhaud and Pavel Stehule
Discussion: https://postgr.es/m/15572-ed1b9ed09503de8a@postgresql.org M src/backend/parser/parse_func.c
M src/include/parser/parse_func.h
M src/test/regress/expected/drop_if_exists.out
M src/test/regress/sql/drop_if_exists.sql
Add DNS SRV support for LDAP server discovery.
commit : 0f086f84ad9041888b789af5871c7432f0e19c5b
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 21 Mar 2019 15:19:03 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 21 Mar 2019 15:19:03 +1300 LDAP servers can be advertised on a network with RFC 2782 DNS SRV
records. The OpenLDAP command-line tools automatically try to find
servers that way, if no server name is provided by the user. Teach
PostgreSQL to do the same using OpenLDAP's support functions, when
building with OpenLDAP.
For now, we assume that HAVE_LDAP_INITIALIZE (an OpenLDAP extension
available since OpenLDAP 2.0 and also present in Apple LDAP) implies
that you also have ldap_domain2hostlist() (which arrived in the same
OpenLDAP version and is also present in Apple LDAP).
Author: Thomas Munro
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/CAEepm=2hAnSfhdsd6vXsM6VZVN0br-FbAZ-O+Swk18S5HkCP=A@mail.gmail.com M doc/src/sgml/client-auth.sgml
M src/backend/libpq/auth.c
M src/backend/libpq/hba.c
Sort the dependent objects before deletion in DROP OWNED BY.
commit : 8aa9dd74b36757342b6208fbfebb5b35c2d67c53
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Mar 2019 18:06:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 20 Mar 2019 18:06:29 -0400 This finishes a task we left undone in commit f1ad067fc, by extending
the delete-in-descending-OID-order rule to deletions triggered by
DROP OWNED BY. We've coped with machine-dependent deletion orders
one time too many, and the new issues caused by Peter G's recent
nbtree hacking seem like the last straw.
Discussion: https://postgr.es/m/E1h6eep-0001Mw-Vd@gemulon.postgresql.org M src/backend/catalog/dependency.c
M src/backend/catalog/pg_shdepend.c
M src/include/catalog/dependency.h
Add index_get_partition convenience function
commit : a6da0047158b8a227f883aeed19eb7fcfbef11fb
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 20 Mar 2019 18:18:50 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 20 Mar 2019 18:18:50 -0300 This new function simplifies some existing coding, as well as supports
future patches.
Discussion: https://postgr.es/m/201901222145.t6wws6t6vrcu@alvherre.pgsql
Reviewed-by: Amit Langote, Jesper Pedersen M src/backend/catalog/partition.c
M src/backend/commands/tablecmds.c
M src/include/catalog/partition.h
Fix spurious compiler warning in nbtxlog.c.
commit : 3d0dcc5c7fb9cfc349d1b2d476a1c0c5d64522bd
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 14:04:35 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 14:04:35 -0700 Cleanup from commit dd299df8.
Per complaint from Tom Lane. M src/backend/access/nbtree/nbtxlog.c
Suppress DETAIL output from a foreign_data test.
commit : 7d3bf73ac416fdd74d6c7d473e0c00a19be90c82
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 13:38:38 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 13:38:38 -0700 Unstable sort order related to changes to nbtree from commit dd299df8
can cause two lines of DETAIL output to be in opposite-of-expected
order. Suppress the output using the same VERBOSITY hack that is used
elsewhere in the foreign_data tests.
Note that the same foreign_data.out DETAIL output was mechanically
updated by commit dd299df8. Only a few such changes were required,
though.
Per buildfarm member batfish.
Discussion: https://postgr.es/m/CAH2-WzkCQ_MtKeOpzozj7QhhgP1unXsK8o9DMAFvDqQFEPpkYQ@mail.gmail.com M src/test/regress/expected/foreign_data.out
M src/test/regress/sql/foreign_data.sql
Restore RI trigger sanity check
commit : 815b20ae0c6ed61a431fba124c736152f0df5022
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 20 Mar 2019 17:28:43 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 20 Mar 2019 17:28:43 -0300 I unnecessarily removed this check in 3de241dba86f because I
misunderstood what the final representation of constraints across a
partitioning hierarchy was to be. Put it back (in both branches).
Discussion: https://postgr.es/m/201901222145.t6wws6t6vrcu@alvherre.pgsql M src/backend/utils/adt/ri_triggers.c
Allow amcheck to re-find tuples using new search.
commit : c1afd175b5b2e5c44f6da34988342e00ecdfb518
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 10:41:36 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 10:41:36 -0700 Teach contrib/amcheck's bt_index_parent_check() function to take
advantage of the uniqueness property of heapkeyspace indexes in support
of a new verification option: non-pivot tuples (non-highkey tuples on
the leaf level) can optionally be re-found using a new search for each,
that starts from the root page. If a tuple cannot be re-found, report
that the index is corrupt.
The new "rootdescend" verification option is exhaustive, and can
therefore make a call to bt_index_parent_check() take a lot longer.
Re-finding tuples during verification is mostly intended as an option
for backend developers, since the corruption scenarios that it alone is
uniquely capable of detecting seem fairly far-fetched.
For example, "rootdescend" verification is much more likely to detect
corruption of the least significant byte of a key from a pivot tuple in
the root page of a B-Tree that already has at least three levels.
Typically, only a few tuples on a cousin leaf page are at risk of
"getting overlooked" by index scans in this scenario. The corrupt key
in the root page is only slightly corrupt: corrupt enough to give wrong
answers to some queries, and yet not corrupt enough to allow the problem
to be detected without verifying agreement between the leaf page and the
root page, skipping at least one internal page level. The existing
bt_index_parent_check() checks never cross more than a single level.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas
Discussion: https://postgr.es/m/CAH2-Wz=yTWnVu+HeHGKb2AGiADL9eprn-cKYAto4MkKOuiGtRQ@mail.gmail.com M contrib/amcheck/Makefile
A contrib/amcheck/amcheck–1.1–1.2.sql
M contrib/amcheck/amcheck.control
M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql
M contrib/amcheck/verify_nbtree.c
M doc/src/sgml/amcheck.sgml
Consider secondary factors during nbtree splits.
commit : fab2502433870d98271ba8751f3794e2ed44140a
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 10:12:19 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 10:12:19 -0700 Teach nbtree to give some consideration to how "distinguishing"
candidate leaf page split points are. This should not noticeably affect
the balance of free space within each half of the split, while still
making suffix truncation truncate away significantly more attributes on
average.
The logic for choosing a leaf split point now uses a fallback mode in
the case where the page is full of duplicates and it isn't possible to
find even a minimally distinguishing split point. When the page is full
of duplicates, the split should pack the left half very tightly, while
leaving the right half mostly empty. Our assumption is that logical
duplicates will almost always be inserted in ascending heap TID order
with v4 indexes. This strategy leaves most of the free space on the
half of the split that will likely be where future logical duplicates of
the same value need to be placed.
The number of cycles added is not very noticeable. This is important
because deciding on a split point takes place while at least one
exclusive buffer lock is held. We avoid using authoritative insertion
scankey comparisons to save cycles, unlike suffix truncation proper. We
use a faster binary comparison instead.
Note that even pg_upgrade'd v3 indexes make use of these optimizations.
Benchmarking has shown that even v3 indexes benefit, despite the fact
that suffix truncation will only truncate non-key attributes in INCLUDE
indexes. Grouping relatively similar tuples together is beneficial in
and of itself, since it reduces the number of leaf pages that must be
accessed by subsequent index scans.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas
Discussion: https://postgr.es/m/CAH2-WzmmoLNQOj9mAD78iQHfWLJDszHEDrAzGTUMG3mVh5xWPw@mail.gmail.com M src/backend/access/nbtree/Makefile
M src/backend/access/nbtree/README
M src/backend/access/nbtree/nbtinsert.c
A src/backend/access/nbtree/nbtsplitloc.c
M src/backend/access/nbtree/nbtutils.c
M src/include/access/nbtree.h
Make heap TID a tiebreaker nbtree index column.
commit : dd299df8189bd00fbe54b72c64f43b6af2ffeccd
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 10:04:01 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 10:04:01 -0700 Make nbtree treat all index tuples as having a heap TID attribute.
Index searches can distinguish duplicates by heap TID, since heap TID is
always guaranteed to be unique. This general approach has numerous
benefits for performance, and is prerequisite to teaching VACUUM to
perform "retail index tuple deletion".
Naively adding a new attribute to every pivot tuple has unacceptable
overhead (it bloats internal pages), so suffix truncation of pivot
tuples is added. This will usually truncate away the "extra" heap TID
attribute from pivot tuples during a leaf page split, and may also
truncate away additional user attributes. This can increase fan-out,
especially in a multi-column index. Truncation can only occur at the
attribute granularity, which isn't particularly effective, but works
well enough for now. A future patch may add support for truncating
"within" text attributes by generating truncated key values using new
opclass infrastructure.
Only new indexes (BTREE_VERSION 4 indexes) will have insertions that
treat heap TID as a tiebreaker attribute, or will have pivot tuples
undergo suffix truncation during a leaf page split (on-disk
compatibility with versions 2 and 3 is preserved). Upgrades to version
4 cannot be performed on-the-fly, unlike upgrades from version 2 to
version 3. contrib/amcheck continues to work with version 2 and 3
indexes, while also enforcing stricter invariants when verifying version
4 indexes. These stricter invariants are the same invariants described
by "3.1.12 Sequencing" from the Lehman and Yao paper.
A later patch will enhance the logic used by nbtree to pick a split
point. This patch is likely to negatively impact performance without
smarter choices around the precise point to split leaf pages at. Making
these two mostly-distinct sets of enhancements into distinct commits
seems like it might clarify their design, even though neither commit is
particularly useful on its own.
The maximum allowed size of new tuples is reduced by an amount equal to
the space required to store an extra MAXALIGN()'d TID in a new high key
during leaf page splits. The user-facing definition of the "1/3 of a
page" restriction is already imprecise, and so does not need to be
revised. However, there should be a compatibility note in the v12
release notes.
Author: Peter Geoghegan
Reviewed-By: Heikki Linnakangas, Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-WzkVb0Kom=R+88fDFb=JSxZMFvbHVC6Mn9LJ2n=X=kS-Uw@mail.gmail.com M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql
M contrib/amcheck/verify_nbtree.c
M contrib/pageinspect/btreefuncs.c
M contrib/pageinspect/expected/btree.out
M contrib/pgstattuple/expected/pgstattuple.out
M doc/src/sgml/indices.sgml
M src/backend/access/common/indextuple.c
M src/backend/access/nbtree/README
M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtpage.c
M src/backend/access/nbtree/nbtree.c
M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/nbtree/nbtutils.c
M src/backend/access/nbtree/nbtxlog.c
M src/backend/access/rmgrdesc/nbtdesc.c
M src/backend/utils/sort/tuplesort.c
M src/include/access/nbtree.h
M src/include/access/nbtxlog.h
M src/test/regress/expected/btree_index.out
M src/test/regress/expected/create_index.out
M src/test/regress/expected/dependency.out
M src/test/regress/expected/event_trigger.out
M src/test/regress/expected/foreign_data.out
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/btree_index.sql
M src/test/regress/sql/create_index.sql
M src/test/regress/sql/foreign_data.sql
Refactor nbtree insertion scankeys.
commit : e5adcb789d80ba565ccacb1ed4341a7c29085238
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 09:30:57 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 20 Mar 2019 09:30:57 -0700 Use dedicated struct to represent nbtree insertion scan keys. Having a
dedicated struct makes the difference between search type scankeys and
insertion scankeys a lot clearer, and simplifies the signature of
several related functions. This is based on a suggestion by Andrey
Lepikhov.
Streamline how unique index insertions cache binary search progress.
Cache the state of in-progress binary searches within _bt_check_unique()
for later instead of having callers avoid repeating the binary search in
an ad-hoc manner. This makes it easy to add a new optimization:
_bt_check_unique() now falls out of its loop immediately in the common
case where it's already clear that there couldn't possibly be a
duplicate.
The new _bt_check_unique() scheme makes it a lot easier to manage cached
binary search effort afterwards, from within _bt_findinsertloc(). This
is needed for the upcoming patch to make nbtree tuples unique by
treating heap TID as a final tiebreaker column. Unique key binary
searches need to restore lower and upper bounds. They cannot simply
continue to use the >= lower bound as the offset to insert at, because
the heap TID tiebreaker column must be used in comparisons for the
restored binary search (unlike the original _bt_check_unique() binary
search, where scankey's heap TID column must be omitted).
Author: Peter Geoghegan, Heikki Linnakangas
Reviewed-By: Heikki Linnakangas, Andrey Lepikhov
Discussion: https://postgr.es/m/CAH2-WzmE6AhUdk9NdWBf4K3HjWXZBX3+umC7mH7+WDrKcRtsOw@mail.gmail.com M contrib/amcheck/verify_nbtree.c
M src/backend/access/nbtree/README
M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtpage.c
M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/nbtree/nbtutils.c
M src/backend/utils/sort/tuplesort.c
M src/include/access/nbtree.h
Get rid of jsonpath_gram.h and jsonpath_scanner.h
commit : 550b9d26f80fa3048f2d5883f0779ed29465960a
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 20 Mar 2019 11:09:07 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 20 Mar 2019 11:09:07 +0300 Jsonpath grammar and scanner are both quite small. It doesn't worth complexity
to compile them separately. This commit makes grammar and scanner be compiled
at once. Therefore, jsonpath_gram.h and jsonpath_gram.h are no longer needed.
This commit also does some reorganization of code in jsonpath_gram.y.
Discussion: https://postgr.es/m/d47b2023-3ecb-5f04-d253-d557547cf74f%402ndQuadrant.com M src/backend/Makefile
M src/backend/utils/adt/.gitignore
M src/backend/utils/adt/Makefile
M src/backend/utils/adt/jsonpath_gram.y
M src/backend/utils/adt/jsonpath_scan.l
M src/include/Makefile
M src/include/utils/.gitignore
D src/include/utils/jsonpath_scanner.h
M src/tools/msvc/Solution.pm
Remove ambiguity for jsonb_path_match() and jsonb_path_exists()
commit : 641fde25233ef3ecc3b8101fe287eea9fceba6fd
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 20 Mar 2019 10:27:56 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 20 Mar 2019 10:27:56 +0300 There are 2-arguments and 4-arguments versions of jsonb_path_match() and
jsonb_path_exists(). But 4-arguments versions have optional 3rd and 4th
arguments, that leads to ambiguity. In the same time 2-arguments versions are
needed only for @@ and @? operators. So, rename 2-arguments versions to
remove the ambiguity.
Catversion is bumped. M src/include/catalog/catversion.h
M src/include/catalog/pg_operator.dat
M src/include/catalog/pg_proc.dat
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/sql/jsonb_jsonpath.sql
Restructure libpq’s handling of send failures.
commit : 1f39a1c0641531e0462a4822f2dba904c5d4d699
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Mar 2019 16:20:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Mar 2019 16:20:20 -0400 Originally, if libpq got a failure (e.g., ECONNRESET) while trying to
send data to the server, it would just report that and wash its hands
of the matter. It was soon found that that wasn't a very pleasant way
of coping with server-initiated disconnections, so we introduced a hack
(pqHandleSendFailure) in the code that sends queries to make it peek
ahead for server error reports before reporting the send failure.
It now emerges that related cases can occur during connection setup;
in particular, as of TLS 1.3 it's unsafe to assume that SSL connection
failures will be reported by SSL_connect rather than during our first
send attempt. We could have fixed that in a hacky way by applying
pqHandleSendFailure after a startup packet send failure, but
(a) pqHandleSendFailure explicitly disclaims suitability for use in any
state except query startup, and (b) the problem still potentially exists
for other send attempts in libpq.
Instead, let's fix this in a more general fashion by eliminating
pqHandleSendFailure altogether, and instead arranging to postpone
all reports of send failures in libpq until after we've made an
attempt to read and process server messages. The send failure won't
be reported at all if we find a server message or detect input EOF.
(Note: this removes one of the reasons why libpq typically overwrites,
rather than appending to, conn->errorMessage: pqHandleSendFailure needed
that behavior so that the send failure report would be replaced if we
got a server message or read failure report. Eventually I'd like to get
rid of that overwrite behavior altogether, but today is not that day.
For the moment, pqSendSome is assuming that its callees will overwrite
not append to conn->errorMessage.)
Possibly this change should get back-patched someday; but it needs
testing first, so let's not consider that till after v12 beta.
Discussion: https://postgr.es/m/CAEepm=2n6Nv+5tFfe8YnkUm1fXgvxR0Mm1FoD+QKG-vLNGLyKg@mail.gmail.com M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-exec.c
M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/fe-protocol2.c
M src/interfaces/libpq/fe-protocol3.c
M src/interfaces/libpq/libpq-int.h
Rename typedef in jsonpath_gram.y from “string” to “JsonPathString”
commit : 5e28b778bf9a5835e702277119c5f92b4dbab45e
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 19 Mar 2019 20:56:13 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 19 Mar 2019 20:56:13 +0300 Reason is the same as in 75c57058b0. M src/backend/utils/adt/jsonpath_gram.y
M src/backend/utils/adt/jsonpath_scan.l
M src/include/utils/jsonpath_scanner.h
Tweak nbtsearch.c function prototype order.
commit : 1009920aaa39e19ecb36409447ece2f8102f4225
author : Peter Geoghegan <pg@bowt.ie>
date : Tue, 19 Mar 2019 09:59:05 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Tue, 19 Mar 2019 09:59:05 -0700 nbtsearch.c's static function prototypes were slightly out of order.
Make the order consistent with static function definition order. M src/backend/access/nbtree/nbtsearch.c
Make checkpoint requests more robust.
commit : 0dfe3d0ef5799e5197adb127a0ec354b61429982
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Mar 2019 12:49:27 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 19 Mar 2019 12:49:27 -0400 Commit 6f6a6d8b1 introduced a delay of up to 2 seconds if we're trying
to request a checkpoint but the checkpointer hasn't started yet (or,
much less likely, our kill() call fails). However buildfarm experience
shows that that's not quite enough for slow or heavily-loaded machines.
There's no good reason to assume that the checkpointer won't start
eventually, so we may as well make the timeout much longer, say 60 sec.
However, if the caller didn't say CHECKPOINT_WAIT, it seems like a bad
idea to be waiting at all, much less for as long as 60 sec. We can
remove the need for that, and make this whole thing more robust, by
adjusting the code so that the existence of a pending checkpoint
request is clear from the contents of shared memory, and making sure
that the checkpointer process will notice it at startup even if it did
not get a signal. In this way there's no need for a non-CHECKPOINT_WAIT
call to wait at all; if it can't send the signal, it can nonetheless
assume that the checkpointer will eventually service the request.
A potential downside of this change is that "kill -INT" on the checkpointer
process is no longer enough to trigger a checkpoint, should anyone be
relying on something so hacky. But there's no obvious reason to do it
like that rather than issuing a plain old CHECKPOINT command, so we'll
assume that nobody is. There doesn't seem to be a way to preserve this
undocumented quasi-feature without introducing race conditions.
Since a principal reason for messing with this is to prevent intermittent
buildfarm failures, back-patch to all supported branches.
Discussion: https://postgr.es/m/27830.1552752475@sss.pgh.pa.us M src/backend/postmaster/checkpointer.c
M src/include/access/xlog.h
Reorder LOCALLOCK structure members to compact the size
commit : 28988a84cf19c01dba3c3fb40e95d9cd6e4888da
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 19 Mar 2019 14:07:08 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 19 Mar 2019 14:07:08 +0100 Save 8 bytes (on x86-64) by filling up padding holes.
Author: Takayuki Tsunakawa <tsunakawa.takay@jp.fujitsu.com>
Discussion: https://www.postgresql.org/message-id/20190219001639.ft7kxir2iz644alf@alap3.anarazel.de M src/include/storage/lock.h
Rename typedef in jsonpath_scan.l from “keyword” to “JsonPathKeyword”
commit : 75c57058b0f5d511a9d80ddfab68a761229d68ea
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 19 Mar 2019 13:34:16 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 19 Mar 2019 13:34:16 +0300 Typedef name should be both unique and non-intersect with variable names
across all the sources. That makes both pg_indent and debuggers happy.
Discussion: https://postgr.es/m/23865.1552936099%40sss.pgh.pa.us M src/backend/utils/adt/jsonpath_scan.l
Ignore attempts to add TOAST table to shared or catalog tables
commit : 590a87025b0aa9ebca53c7b71ddf036e5acd8f08
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 19 Mar 2019 10:48:03 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 19 Mar 2019 10:48:03 +0100 Running ALTER TABLE on any table will check if a TOAST table needs to be
added. On shared tables, this would previously fail, thus effectively
disabling ALTER TABLE for those tables. On (non-shared) system
catalogs, on the other hand, it would add a TOAST table, even though we
don't really want TOAST tables on some system catalogs. In some cases,
it would also fail with an error "AccessExclusiveLock required to add
toast table.", depending on what locks the ALTER TABLE actions had
already taken.
So instead, just ignore attempts to add TOAST tables to such tables,
outside of bootstrap mode, pretending they don't need one.
This allows running ALTER TABLE on such tables without messing up the
TOAST situation. Legitimate uses for ALTER TABLE on system catalogs
include setting reloptions (say, fillfactor or autovacuum settings).
(All this still requires allow_system_table_mods, which is independent
of this.)
Discussion: https://www.postgresql.org/message-id/flat/e49f825b-fb25-0bc8-8afc-d5ad895c7975@2ndquadrant.com M src/backend/catalog/toasting.c
Fix whitespace
commit : e537ac5182f8cfa7244a8c8ae772b787b2288605
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 19 Mar 2019 10:28:34 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 19 Mar 2019 10:28:34 +0100 M src/backend/utils/adt/jsonpath_gram.y
M src/backend/utils/adt/jsonpath_scan.l
Fix bug in support for collation attributes on older ICU versions
commit : 1f050c08f91d866c560344d4510404ecd2763cbf
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 19 Mar 2019 09:37:46 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 19 Mar 2019 09:37:46 +0100 Unrecognized attribute names are supposed to be ignored. But the code
would error out on an unrecognized attribute value even if it did not
recognize the attribute name. So unrecognized attributes wouldn't
really be ignored unless the value happened to be one that matched a
recognized value. This would break some important cases where the
attribute would be processed by ucol_open() directly. Fix that and
add a test case.
The restructured code should also avoid compiler warnings about
initializing a UColAttribute value to -1, because the type might be an
unsigned enum. (reported by Andres Freund) M src/backend/utils/adt/pg_locale.c
M src/test/regress/expected/collate.icu.utf8.out
M src/test/regress/sql/collate.icu.utf8.sql
Fix copyfuncs/equalfuncs support for VacuumStmt.
commit : 53680c116ce8c501e4081332d32ba0e93aa1aaa2
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 18 Mar 2019 23:20:35 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 18 Mar 2019 23:20:35 -0400 Commit 6776142a07afb4c28961f27059d800196902f5f1 failed to do this,
and the buildfarm broke.
Patch by me, per advice from Tom Lane and Michael Paquier.
Discussion: http://postgr.es/m/13988.1552960403@sss.pgh.pa.us M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
Implement OR REPLACE option for CREATE AGGREGATE.
commit : 01bde4fa4c24f4eea0a634d8fcad0b376efda6b1
author : Andrew Gierth <rhodiumtoad@postgresql.org>
date : Tue, 19 Mar 2019 01:16:50 +0000
committer: Andrew Gierth <rhodiumtoad@postgresql.org>
date : Tue, 19 Mar 2019 01:16:50 +0000 Aggregates have acquired a dozen or so optional attributes in recent
years for things like parallel query and moving-aggregate mode; the
lack of an OR REPLACE option to add or change these for an existing
agg makes extension upgrades gratuitously hard. Rectify. M doc/src/sgml/ref/create_aggregate.sgml
M src/backend/catalog/pg_aggregate.c
M src/backend/catalog/pg_proc.c
M src/backend/commands/aggregatecmds.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/parser/gram.y
M src/backend/tcop/utility.c
M src/include/catalog/pg_aggregate.h
M src/include/commands/defrem.h
M src/include/nodes/parsenodes.h
M src/test/regress/expected/create_aggregate.out
M src/test/regress/sql/create_aggregate.sql
Fix memory leak in printtup.c.
commit : f2004f19ed9c9228d3ea2b12379ccb4b9212641f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Mar 2019 17:54:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 18 Mar 2019 17:54:24 -0400 Commit f2dec34e1 changed things so that printtup's output stringinfo
buffer was allocated outside the per-row temporary context, not inside
it. This creates a need to free that buffer explicitly when the temp
context is freed, but that was overlooked. In most cases, this is all
happening inside a portal or executor context that will go away shortly
anyhow, but that's not always true. Notably, the stringinfo ends up
getting leaked when JDBC uses row-at-a-time fetches. For a query
that returns wide rows, that adds up after awhile.
Per bug #15700 from Matthias Otterbach. Back-patch to v11 where the
faulty code was added.
Discussion: https://postgr.es/m/15700-8c408321a87d56bb@postgresql.org M src/backend/access/common/printtup.c
Fix typos in sgml docs about RefetchForeignRow().
commit : 11180a5015e9c6299ee732fa587b3a8bc6dca6b2
author : Andres Freund <andres@anarazel.de>
date : Mon, 18 Mar 2019 13:32:41 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 18 Mar 2019 13:32:41 -0700 I screwed this up in ad0bda5d24e.
Reported-By: Jie Zhang, Michael Paquier, Etsuro Fujita
Discussion: https://postgr.es/m/1396E95157071C4EBBA51892C5368521017F2DA203@G08CNEXMBPEKD02.g08.fujitsu.local M doc/src/sgml/fdwhandler.sgml
Remove leftover reference to oid column.
commit : 7571ce6f11f24594274fd4956bd4d1114eebd485
author : Andres Freund <andres@anarazel.de>
date : Mon, 18 Mar 2019 13:10:29 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 18 Mar 2019 13:10:29 -0700 I (Andres) missed this in 578b229718e8.
Author: John Naylor
Discussion: https://postgr.es/m/CACPNZCtd+ckUgibRFs9KewK4Yr5rj3Oipefquupw+XJZebFhrA@mail.gmail.com M contrib/vacuumlo/vacuumlo.c
Don’t auto-restart per-database autoprewarm workers.
commit : 1459e84cb2e57649627753ad1279428d35590df6
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 18 Mar 2019 15:21:09 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 18 Mar 2019 15:21:09 -0400 We should try to prewarm each database only once. Otherwise, if
prewarming fails for some reason, it will just keep retrying in an
infnite loop. This can happen if, for example, the database has been
dropped. The existing code was intended to implement the try-once
behavior, but failed to do so because it neglected to set
worker.bgw_restart_time to BGW_NEVER_RESTART.
Mithun Cy, per a report from Hans Buschmann
Discussion: http://postgr.es/m/CA+hUKGKpQJCWcgyy3QTC9vdn6uKAR_8r__A-MMm2GYfj45caag@mail.gmail.com M contrib/pg_prewarm/autoprewarm.c
Revise parse tree representation for VACUUM and ANALYZE.
commit : 6776142a07afb4c28961f27059d800196902f5f1
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 18 Mar 2019 15:14:52 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 18 Mar 2019 15:14:52 -0400 Like commit f41551f61f9cf4eedd5b7173f985a3bdb4d9858c, this aims
to make it easier to add non-Boolean options to VACUUM (or, in
this case, to ANALYZE). Instead of building up a bitmap of
options directly in the parser, build up a list of DefElem
objects and let ExecVacuum() sort it out; right now, we make
no use of the fact that a DefElem can carry an associated value,
but it will be easy to make that change in the future.
Masahiko Sawada
Discussion: http://postgr.es/m/CAD21AoATE4sn0jFFH3NcfUZXkU2BMbjBWB_kDj-XWYA-LXDcQA@mail.gmail.com M src/backend/commands/vacuum.c
M src/backend/parser/gram.y
M src/backend/tcop/utility.c
M src/include/commands/vacuum.h
M src/include/nodes/parsenodes.h
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Fold vacuum’s ‘int options’ parameter into VacuumParams.
commit : f41551f61f9cf4eedd5b7173f985a3bdb4d9858c
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 18 Mar 2019 13:57:33 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 18 Mar 2019 13:57:33 -0400 Many places need both, so this allows a few functions to take one
fewer parameter. More importantly, as soon as we add a VACUUM
option that takes a non-Boolean parameter, we need to replace
'int options' with a struct, and it seems better to think
of adding more fields to VacuumParams rather than passing around
both VacuumParams and a separate struct as well.
Patch by me, reviewed by Masahiko Sawada
Discussion: http://postgr.es/m/CA+Tgmob6g6-s50fyv8E8he7APfwCYYJ4z0wbZC2yZeSz=26CYQ@mail.gmail.com M src/backend/access/heap/vacuumlazy.c
M src/backend/commands/analyze.c
M src/backend/commands/vacuum.c
M src/backend/postmaster/autovacuum.c
M src/include/access/heapam.h
M src/include/commands/vacuum.h
Fix optimization of foreign-key on update actions
commit : 1ffa59a85cb40a61f4523fb03c8960db97eea124
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 18 Mar 2019 17:01:40 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 18 Mar 2019 17:01:40 +0100 In RI_FKey_pk_upd_check_required(), we check among other things
whether the old and new key are equal, so that we don't need to run
cascade actions when nothing has actually changed. This was using the
equality operator. But the effect of this is that if a value in the
primary key is changed to one that "looks" different but compares as
equal, the update is not propagated. (Examples are float -0 and 0 and
case-insensitive text.) This appears to violate the SQL standard, and
it also behaves inconsistently if in a multicolumn key another key is
also updated that would cause the row to compare as not equal.
To fix, if we are looking at the PK table in ri_KeysEqual(), then do a
bytewise comparison similar to record_image_eq() instead of using the
equality operators. This only makes a difference for ON UPDATE
CASCADE, but for consistency we treat all changes to the PK the same. For
the FK table, we continue to use the equality operators.
Discussion: https://www.postgresql.org/message-id/flat/3326fc2e-bc02-d4c5-e3e5-e54da466e89a@2ndquadrant.com M src/backend/utils/adt/datum.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/adt/rowtypes.c
M src/include/utils/datum.h
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Remove unused macro
commit : fb5806533f9fe0433290d84c9b019399cd69e9c2
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 18 Mar 2019 09:13:08 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 18 Mar 2019 09:13:08 +0100 It has never been used. M src/bin/pg_dump/parallel.c
Revert 4178d8b91c
commit : a0478b69985056965a5737184279a99bde421f69
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 18 Mar 2019 09:54:29 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 18 Mar 2019 09:54:29 +0300 As it was agreed to worsen the code readability.
Discussion: https://postgr.es/m/ecfcfb5f-3233-eaa9-0c83-07056fb49a83%402ndquadrant.com M src/backend/utils/adt/jsonpath_exec.c
Refactor more code logic to update the control file
commit : 8b938d36f7446e76436ca4a8ddcebbebaeaab480
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Mar 2019 12:59:35 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Mar 2019 12:59:35 +0900 ce6afc6 has begun the refactoring work by plugging pg_rewind into a
central routine to update the control file, and left around two extra
copies, with one in xlog.c for the backend and one in pg_resetwal.c. By
adding an extra option to the central routine in controldata_utils.c to
control if a flush of the control file needs to be done, it is proving
to be straight-forward to make xlog.c and pg_resetwal.c use the central
code path at the condition of moving the wait event tracking there.
Hence, this allows to have only one central code path to update the
control file, shaving the code from the duplicates.
This refactoring actually fixes a problem in pg_resetwal. Previously,
the control file was first removed before being recreated. So if a
crash happened between the moment the file was removed and the moment
the file was created, then it would have been possible to not have a
control file anymore in the database folder.
Author: Fabien Coelho
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/alpine.DEB.2.21.1903170935210.2506@lancre M src/backend/access/transam/xlog.c
M src/bin/pg_resetwal/pg_resetwal.c
M src/bin/pg_rewind/pg_rewind.c
M src/common/controldata_utils.c
M src/include/common/controldata_utils.h
Fix pg_rewind when rewinding new database with tables included
commit : a7eadaaaaf089994279488f795bdedd9ded1682a
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Mar 2019 10:34:45 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Mar 2019 10:34:45 +0900 This fixes an issue introduced by 266b6ac, which has added filters to
exclude file patterns on the target and source data directories to
reduce the number of files transferred. Filters get applied to both
the target and source data files, and include pg_internal.init which is
present for each database once relations are created on it. However, if
the target differed from the source with at least one new database with
relations, the rewind would fail due to the exclusion filters applied on
the target files, causing pg_internal.init to still be present on the
target database folder, while its contents should have been completely
removed so as there is nothing remaining inside at the time of the
folder deletion.
Applying exclusion filters on the source files is fine, because this way
the amount of data copied from the source to the target is reduced. And
actually, not applying the filters on the target is what pg_rewind
should do, because this causes such files to be automatically removed
during the rewind on the target. Exclusion filters apply to paths which
are removed or recreated automatically at startup, so removing all those
files on the target during the rewind is a win.
The existing set of TAP tests already stresses the rewind of databases,
but it did not include any tables on those newly-created databases.
Creating extra tables in this case is enough to reproduce the failure,
so the existing tests are extended to close the gap.
Reported-by: Mithun Cy
Author: Michael Paquier
Discussion: https://postgr.es/m/CADq3xVYt6_pO7ZzmjOqPgY9HWsL=kLd-_tNyMtdfjKqEALDyTA@mail.gmail.com
Backpatch-through: 11 M src/bin/pg_rewind/filemap.c
M src/bin/pg_rewind/t/002_databases.pl
M src/bin/pg_rewind/t/RewindTest.pm
Error out in pg_checksums on incompatible block size
commit : fa3395659561b564051a2bbd3997de8e2923c8e3
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Mar 2019 09:11:52 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 18 Mar 2019 09:11:52 +0900 pg_checksums is compiled with a given block size and has a hard
dependency to it per the way checksums are calculated via
checksum_impl.h, and trying to use the tool on a data folder which has
not the same block size would result in incorrect checksum calculations
and/or block read errors, meaning that the data folder is corrupted.
This is harmless as checksums are only checked now, but very confusing
for the user so issue an error properly if the block size used at
compilation and the block size used in the data folder do not match.
Reported-by: Sergei Kornilov
Author: Michael Banck, Michael Paquier
Reviewed-by: Fabien Coelho, Magnus Hagander
Discussion: https://postgr.es/m/20190317054657.GA3357@paquier.xyz
ackpatch-through: 11 M src/bin/pg_checksums/pg_checksums.c
Beautify initialization of JsonValueList and JsonLikeRegexContext
commit : 4178d8b91cb943b422d1837b4b7798576d88995a
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 17 Mar 2019 12:58:26 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 17 Mar 2019 12:58:26 +0300 Instead of tricky assignment to {0} introduce special macros, which
explicitly initialize every field. M src/backend/utils/adt/jsonpath_exec.c
Apply const qualifier to keywords of jsonpath_scan.l
commit : aa1b7f386687dec17ffa62d13026580050734632
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 17 Mar 2019 12:50:38 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 17 Mar 2019 12:50:38 +0300 Discussion: https://postgr.es/m/CAEeOP_a-Pfy%3DU9-f%3DgQ0AsB8FrxrC8xCTVq%2BeO71-2VoWP5cag%40mail.gmail.com
Author: Mark G M src/backend/utils/adt/jsonpath_scan.l
Remove some make rules added in 142c400d72
commit : c183a07f279d1fba8ccea1baf7210e8fafbaa097
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 17 Mar 2019 11:14:49 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 17 Mar 2019 11:14:49 +0300 Because they fail build of jsonpath_scan.c. M src/backend/utils/adt/Makefile
Fix make rules for jsonpath grammar making them similar to SQL grammar
commit : 142c400d72f77e7249306b80e0149f4fd35c6304
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 17 Mar 2019 10:51:28 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 17 Mar 2019 10:51:28 +0300 Reported-by: Jeff Janes, Tom Lane
Discussion: https://postgr.es/m/CAMkU%3D1w1qBvoW82ZTFpAKae027R-2OHw-m6ALe0VQRNAFueBVA%40mail.gmail.com M src/backend/Makefile
M src/backend/utils/adt/Makefile
M src/include/Makefile
Add support for collation attributes on older ICU versions
commit : b8f9a2a69a279d118e366a0d3d45caa84a7620b1
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 17 Mar 2019 08:16:33 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 17 Mar 2019 08:16:33 +0100 Starting in ICU 54, collation customization attributes can be
specified in the locale string, for example
"@colStrength=primary;colCaseLevel=yes". Add support for this for
older ICU versions as well, by adding some minimal parsing of the
attributes in the locale string and calling ucol_setAttribute() on
them. This is essentially what never ICU versions do internally in
ucol_open(). This was we can offer this functionality in a consistent
way in all ICU versions supported by PostgreSQL.
Also add some tests for ICU collation customization.
Reported-by: Daniel Verite <daniel@manitou-mail.org>
Discussion: https://www.postgresql.org/message-id/0270ebd4-f67c-8774-1a5a-91adfb9bb41f@2ndquadrant.com M src/backend/utils/adt/pg_locale.c
M src/test/regress/expected/collate.icu.utf8.out
M src/test/regress/sql/collate.icu.utf8.sql
Fix compiler warning in jsonpath_exec.c
commit : 042162d6281a7daf1291931ee7b0a5641d3a73d7
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 17 Mar 2019 10:10:21 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 17 Mar 2019 10:10:21 +0300 Warning was observed in gcc 4.4.6, gcc 4.4.7 and probably others.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/25151.1552751426%40sss.pgh.pa.us M src/backend/utils/adt/jsonpath_exec.c
Remove another unnecessary application_name specification in test
commit : 0176eb210e445e8a911c7df79997c7ab62e86dcc
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 16 Mar 2019 22:38:59 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 16 Mar 2019 22:38:59 +0100 see 8e93a516e68bac3c329fd2e7f423ee9aceca943a M src/test/subscription/t/100_bugs.pl
Further adjust the tests for the hyperbolic functions.
commit : c43ecdee0fff529ca47a90aea0a6954690af045c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 Mar 2019 15:50:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 Mar 2019 15:50:13 -0400 It looks like we can leave in most of the test cases for Infinity/NaN
inputs, but buildfarm member jacana gets the wrong answer for acosh(Inf).
It's not worth carrying a variant expected file for that, so just disable
that one test.
Discussion: https://postgr.es/m/E1h3nUY-0000sM-Vf@gemulon.postgresql.org M src/test/regress/expected/float8.out
M src/test/regress/sql/float8.sql
Suppress -Wimplicit-fallthrough warnings in new jsonpath code.
commit : 20f7c3d5606254d8870697f15fd7a7b4e602e1e1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 Mar 2019 12:34:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 16 Mar 2019 12:34:46 -0400 Per buildfarm. See commit 41c912cad for precedent. M src/backend/utils/adt/jsonpath.c
Update copyright year in files added by 1bb5e78218.
commit : f27314ff9a0eb60b75bb576c3629c8849f7698c1
author : Amit Kapila <akapila@postgresql.org>
date : Sat, 16 Mar 2019 16:00:38 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Sat, 16 Mar 2019 16:00:38 +0530 M src/backend/partitioning/partdesc.c
M src/include/partitioning/partdesc.h
Numeric error suppression in jsonpath
commit : 16d489b0fe058e527619f5e9d92fd7ca3c6c2994
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sat, 16 Mar 2019 12:21:19 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sat, 16 Mar 2019 12:21:19 +0300 Add support of numeric error suppression to jsonpath as it's required by
standard. This commit doesn't use PG_TRY()/PG_CATCH() in order to implement
that. Instead, it provides internal versions of numeric functions used, which
support error suppression.
Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com
Author: Alexander Korotkov, Nikita Glukhov
Reviewed-by: Tomas Vondra M doc/src/sgml/func.sgml
M src/backend/utils/adt/float.c
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/adt/numeric.c
M src/include/utils/float.h
M src/include/utils/numeric.h
M src/test/regress/expected/jsonb_jsonpath.out
Partial implementation of SQL/JSON path language
commit : 72b6460336e86ad5cafd3426af6013c7d8457367
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sat, 16 Mar 2019 12:15:37 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sat, 16 Mar 2019 12:15:37 +0300 SQL 2016 standards among other things contains set of SQL/JSON features for
JSON processing inside of relational database. The core of SQL/JSON is JSON
path language, allowing access parts of JSON documents and make computations
over them. This commit implements partial support JSON path language as
separate datatype called "jsonpath". The implementation is partial because
it's lacking datetime support and suppression of numeric errors. Missing
features will be added later by separate commits.
Support of SQL/JSON features requires implementation of separate nodes, and it
will be considered in subsequent patches. This commit includes following
set of plain functions, allowing to execute jsonpath over jsonb values:
* jsonb_path_exists(jsonb, jsonpath[, jsonb, bool]),
* jsonb_path_match(jsonb, jsonpath[, jsonb, bool]),
* jsonb_path_query(jsonb, jsonpath[, jsonb, bool]),
* jsonb_path_query_array(jsonb, jsonpath[, jsonb, bool]).
* jsonb_path_query_first(jsonb, jsonpath[, jsonb, bool]).
This commit also implements "jsonb @? jsonpath" and "jsonb @@ jsonpath", which
are wrappers over jsonpath_exists(jsonb, jsonpath) and jsonpath_predicate(jsonb,
jsonpath) correspondingly. These operators will have an index support
(implemented in subsequent patches).
Catversion bumped, to add new functions and operators.
Code was written by Nikita Glukhov and Teodor Sigaev, revised by me.
Documentation was written by Oleg Bartunov and Liudmila Mantrova. The work
was inspired by Oleg Bartunov.
Discussion: https://postgr.es/m/fcc6fc6a-b497-f39a-923d-aa34d0c588e8%402ndQuadrant.com
Author: Nikita Glukhov, Teodor Sigaev, Alexander Korotkov, Oleg Bartunov, Liudmila Mantrova
Reviewed-by: Tomas Vondra, Andrew Dunstan, Pavel Stehule, Alexander Korotkov M doc/src/sgml/biblio.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/json.sgml
M src/backend/Makefile
M src/backend/catalog/system_views.sql
A src/backend/utils/adt/.gitignore
M src/backend/utils/adt/Makefile
M src/backend/utils/adt/jsonb.c
M src/backend/utils/adt/jsonb_util.c
A src/backend/utils/adt/jsonpath.c
A src/backend/utils/adt/jsonpath_exec.c
A src/backend/utils/adt/jsonpath_gram.y
A src/backend/utils/adt/jsonpath_scan.l
M src/backend/utils/adt/regexp.c
M src/backend/utils/errcodes.txt
M src/include/catalog/catversion.h
M src/include/catalog/pg_operator.dat
M src/include/catalog/pg_proc.dat
M src/include/catalog/pg_type.dat
M src/include/regex/regex.h
M src/include/utils/.gitignore
M src/include/utils/jsonb.h
A src/include/utils/jsonpath.h
A src/include/utils/jsonpath_scanner.h
A src/test/regress/expected/jsonb_jsonpath.out
A src/test/regress/expected/jsonpath.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
A src/test/regress/sql/jsonb_jsonpath.sql
A src/test/regress/sql/jsonpath.sql
M src/tools/msvc/Mkvcbuild.pm
M src/tools/msvc/Solution.pm
M src/tools/pgindent/typedefs.list
Avoid casting away a const
commit : 893d6f8a1f9b43da805124e93cbf0f7aea890ad4
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 16 Mar 2019 10:13:03 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 16 Mar 2019 10:13:03 +0100 M src/backend/access/transam/xlog.c
M src/backend/utils/misc/guc.c
M src/include/access/xlog.h
Don’t propagate PGAPPNAME through pg_ctl in tests
commit : 8e93a516e68bac3c329fd2e7f423ee9aceca943a
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 15 Mar 2019 21:24:05 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 15 Mar 2019 21:24:05 +0100 When libpq is loaded in the server (for instance, by
libpqwalreceiver), it may use libpq environment variables set in the
postmaster environment for connection parameter defaults. This has
some confusing effects in our test suites. For example, the TAP test
infrastructure sets PGAPPNAME to allow identifying clients in the
server log. But this environment variable is also inherited by
temporary servers started with pg_ctl and is then in turn used by
libpqwalreceiver as the application_name for connecting to remote
servers where it then shows up in pg_stat_replication and is relevant
for things like synchronous_standby_names. Replication already has a
suitable default for application_name, and overriding that
accidentally then requires the individual test cases to re-override
that, which is all very confusing and unnecessary.
To fix, unset PGAPPNAME temporarily before running pg_ctl start or
restart in the tests.
More comprehensive approaches like unsetting all environment variables
in pg_ctl were considered but might be too complicated to achieve
portably.
The now unnecessary re-overriding of application_name by test cases is
also removed.
Reviewed-by: Noah Misch <noah@leadboat.com>
Discussion: https://www.postgresql.org/message-id/flat/33383613-690e-6f1b-d5ba-4957ff40f6ce@2ndquadrant.com M src/bin/pg_rewind/t/RewindTest.pm
M src/test/perl/PostgresNode.pm
M src/test/recovery/t/004_timeline_switch.pl
M src/test/subscription/t/001_rep_changes.pl
M src/test/subscription/t/002_types.pl
M src/test/subscription/t/003_constraints.pl
M src/test/subscription/t/004_sync.pl
M src/test/subscription/t/005_encoding.pl
M src/test/subscription/t/006_rewrite.pl
M src/test/subscription/t/007_ddl.pl
M src/test/subscription/t/008_diff_schema.pl
M src/test/subscription/t/009_matviews.pl
M src/test/subscription/t/010_truncate.pl
Use correct connection name variable in ecpglib.
commit : c21d6033f77353623f8642c5541e0d002d986f59
author : Michael Meskes <meskes@postgresql.org>
date : Fri, 15 Mar 2019 22:35:24 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Fri, 15 Mar 2019 22:35:24 +0100 Fixed-by: Kuroda-san <kuroda.hayato@jp.fujitsu.com> M src/interfaces/ecpg/ecpglib/prepare.c
Improve code comments in b0eaa4c51b.
commit : 06c8a5090ed9ec188557a86d4de11384f5128ec0
author : Amit Kapila <akapila@postgresql.org>
date : Sat, 16 Mar 2019 06:55:56 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Sat, 16 Mar 2019 06:55:56 +0530 Author: John Naylor
Discussion: https://postgr.es/m/CACPNZCswjyGJxTT=mxHgK=Z=mJ9uJ4WEx_UO=bNwpR_i0EaHHg@mail.gmail.com M src/backend/storage/freespace/freespace.c
Further reduce memory footprint of CLOBBER_CACHE_ALWAYS testing.
commit : d3f48dfae42f9655425d1f58f396e495c7fb7812
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Mar 2019 13:46:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 15 Mar 2019 13:46:26 -0400 Some buildfarm members using CLOBBER_CACHE_ALWAYS have been having OOM
problems of late. Commit 2455ab488 addressed this problem by recovering
space transiently used within RelationBuildPartitionDesc, but it turns
out that leaves quite a lot on the table, because other subroutines of
RelationBuildDesc also leak memory like mad. Let's move the temp-context
management into RelationBuildDesc so that leakage from the other
subroutines is also recovered.
I examined this issue by arranging for postgres.c to dump the size of
MessageContext just before resetting it in each command cycle, and
then running the update.sql regression test (which is one of the two
that are seeing buildfarm OOMs) with and without CLOBBER_CACHE_ALWAYS.
Before 2455ab488, the peak space usage with CCA was as much as 250MB.
That patch got it down to ~80MB, but with this patch it's about 0.5MB,
and indeed the space usage now seems nearly indistinguishable from a
non-CCA build.
RelationBuildDesc's traditional behavior of not worrying about leaking
transient data is of many years' standing, so I'm pretty hesitant to
change that without more evidence that it'd be useful in a normal build.
(So far as I can see, non-CCA memory consumption is about the same with
or without this change, whuch if anything suggests that it isn't useful.)
Hence, configure the patch so that we recover space only when
CLOBBER_CACHE_ALWAYS or CLOBBER_CACHE_RECURSIVELY is defined. However,
that choice can be overridden at compile time, in case somebody would
like to do some performance testing and try to develop evidence for
changing that decision.
It's possible that we ought to back-patch this change, but in the
absence of back-branch OOM problems in the buildfarm, I'm not in
a hurry to do that.
Discussion: https://postgr.es/m/CA+TgmoY3bRmGB6-DUnoVy5fJoreiBJ43rwMrQRCdPXuKt4Ykaw@mail.gmail.com M src/backend/partitioning/partdesc.c
M src/backend/utils/cache/relcache.c
PL/Tcl: Improve trigger tests organization
commit : aefcc2bba211b738b3dd3cb393d9cdfcbcdc83cd
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 15 Mar 2019 11:21:01 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 15 Mar 2019 11:21:01 +0100 The trigger tests for PL/Tcl were spread aroud pltcl_setup.sql and
pltcl_queries.sql, mixed with other tests, which makes them hard to
follow and edit. Move all the trigger-related pieces to a new file
pltcl_trigger.sql. This also makes the test setup more similar to
plperl and plpython. M src/pl/tcl/Makefile
M src/pl/tcl/expected/pltcl_queries.out
M src/pl/tcl/expected/pltcl_setup.out
A src/pl/tcl/expected/pltcl_trigger.out
M src/pl/tcl/sql/pltcl_queries.sql
M src/pl/tcl/sql/pltcl_setup.sql
A src/pl/tcl/sql/pltcl_trigger.sql
Add walreceiver API to get remote server version
commit : 69039fda837d7a9c78e42b9dd5291d454e71f460
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 15 Mar 2019 10:16:26 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 15 Mar 2019 10:16:26 +0100 Add a separate walreceiver API function walrcv_server_version() to get
the version of the remote server, instead of doing it as part of
walrcv_identify_system(). This allows the server version to be
available even for uses that don't call IDENTIFY_SYSTEM, and it seems
cleaner anyway.
This is for an upcoming patch, not currently used.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://www.postgresql.org/message-id/20190115071359.GF1433@paquier.xyz M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/backend/replication/logical/worker.c
M src/backend/replication/walreceiver.c
M src/include/replication/walreceiver.h
Fix typo related to to_tsvector() in tests of json and jsonb
commit : 4e197bf19556a1699b0e11e1ff111d77d09f6f80
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 15 Mar 2019 16:20:11 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 15 Mar 2019 16:20:11 +0900 Author: Sho Kato
Reviewed-by: Kyotaro Horiguchi
Discussion: https://postgr.es/m/25C1C6B2E7BE044889E4FE8643A58BA963E1D03D@G01JPEXMBKW03 M src/test/regress/expected/json.out
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql
Enable parallel query with SERIALIZABLE isolation.
commit : bb16aba50c9492490a0b57e600a932798f45cd4f
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 15 Mar 2019 16:23:46 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 15 Mar 2019 16:23:46 +1300 Previously, the SERIALIZABLE isolation level prevented parallel query
from being used. Allow the two features to be used together by
sharing the leader's SERIALIZABLEXACT with parallel workers.
An extra per-SERIALIZABLEXACT LWLock is introduced to make it safe to
share, and new logic is introduced to coordinate the early release
of the SERIALIZABLEXACT required for the SXACT_FLAG_RO_SAFE
optimization, as follows:
The first backend to observe the SXACT_FLAG_RO_SAFE flag (set by
some other transaction) will 'partially release' the SERIALIZABLEXACT,
meaning that the conflicts and locks it holds are released, but the
SERIALIZABLEXACT itself will remain active because other backends
might still have a pointer to it.
Whenever any backend notices the SXACT_FLAG_RO_SAFE flag, it clears
its own MySerializableXact variable and frees local resources so that
it can skip SSI checks for the rest of the transaction. In the
special case of the leader process, it transfers the SERIALIZABLEXACT
to a new variable SavedSerializableXact, so that it can be completely
released at the end of the transaction after all workers have exited.
Remove the serializable_okay flag added to CreateParallelContext() by
commit 9da0cc35, because it's now redundant.
Author: Thomas Munro
Reviewed-by: Haribabu Kommi, Robert Haas, Masahiko Sawada, Kevin Grittner
Discussion: https://postgr.es/m/CAEepm=0gXGYhtrVDWOTHS8SQQy_=S9xo+8oCxGLWZAOoeJ=yzQ@mail.gmail.com M doc/src/sgml/monitoring.sgml
M doc/src/sgml/parallel.sgml
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/transam/parallel.c
M src/backend/access/transam/xact.c
M src/backend/executor/execParallel.c
M src/backend/optimizer/plan/planner.c
M src/backend/storage/lmgr/lwlock.c
M src/backend/storage/lmgr/predicate.c
M src/backend/utils/resowner/resowner.c
M src/include/access/parallel.h
M src/include/storage/lwlock.h
M src/include/storage/predicate.h
M src/include/storage/predicate_internals.h
A src/test/isolation/expected/serializable-parallel-2.out
A src/test/isolation/expected/serializable-parallel.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/serializable-parallel-2.spec
A src/test/isolation/specs/serializable-parallel.spec
During pg_upgrade, conditionally skip transfer of FSMs.
commit : 13e8643bfc29d3c1455c0946281cdfc24758ffb6
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 15 Mar 2019 08:25:57 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 15 Mar 2019 08:25:57 +0530 If a heap on the old cluster has 4 pages or fewer, and the old cluster
was PG v11 or earlier, don't copy or link the FSM. This will shrink
space usage for installations with large numbers of small tables.
This will allow pg_upgrade to take advantage of commit b0eaa4c51b where
we have avoided creation of the free space map for small heap relations.
Author: John Naylor
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/CACPNZCu4cOdm3uGnNEGXivy7Gz8UWyQjynDpdkPGabQ18_zK6g%40mail.gmail.com M doc/src/sgml/ref/pgupgrade.sgml
M src/bin/pg_upgrade/info.c
M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pg_upgrade/relfilenode.c
Reorder identity regression test
commit : 2fadf24e249bd72fc517663a91a233437460671c
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 15 Mar 2019 00:16:45 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 15 Mar 2019 00:16:45 +0100 The previous test order had the effect that if something was wrong
with the identity functionality, the create_table_like test would
likely fail or crash first, which is confusing. Reorder so that the
identity test comes before create_table_like. M src/test/regress/expected/identity.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/identity.sql
Fix some oversights in commit 2455ab488.
commit : de570047993bd5fd65ad2bdf6b0acf5b8939bcb3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Mar 2019 18:36:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Mar 2019 18:36:26 -0400 The idea was to generate all the junk in a destroyable subcontext rather
than leaking it in the caller's context, but partition_bounds_create was
still being called in the caller's context, allowing plenty of scope for
leakage. Also, get_rel_relkind() was still being called in the rel's
rd_pdcxt, creating a risk of session-lifespan memory wastage.
Simplify the logic a bit while at it. Also, reduce rd_pdcxt to
ALLOCSET_SMALL_SIZES, since it seems likely to not usually be big.
Probably something like this needs to be back-patched into v11,
but for now let's get some buildfarm testing on this.
Discussion: https://postgr.es/m/15943.1552601288@sss.pgh.pa.us M src/backend/partitioning/partdesc.c
Improve code comment
commit : 61dc407893600f551dbcbc235d1dccd134f43da0
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 22:44:21 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 22:44:21 +0100 M src/backend/commands/copy.c
Remove unused #include
commit : 8bee36708f6ee4bf93be68f9a368379b0e9c6474
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 22:03:14 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 22:03:14 +0100 M src/backend/executor/execMain.c
Add BKI_DEFAULT to pg_class.relrewrite
commit : b13a913607b9b304d16029361b1b17e10783cf7c
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 21:25:39 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 21:25:39 +0100 This column is always 0 on disk, so it doesn't have to be tracked
separately for each entry. M src/include/catalog/pg_class.dat
M src/include/catalog/pg_class.h
Ensure dummy paths have correct required_outer if rel is parameterized.
commit : 0a9d7e1f6d814799e6cd5046513702dd1fe38929
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Mar 2019 12:16:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Mar 2019 12:16:09 -0400 The assertions added by commits 34ea1ab7f et al found another problem:
set_dummy_rel_pathlist and mark_dummy_rel were failing to label
the dummy paths they create with the correct outer_relids, in case
the relation is necessarily parameterized due to having lateral
references in its tlist. It's likely that this has no user-visible
consequences in production builds, at the moment; but still an assertion
failure is a bad thing, so back-patch the fix.
Per bug #15694 from Roman Zharkov (via Alexander Lakhin)
and an independent report by Tushar Ahuja.
Discussion: https://postgr.es/m/15694-74f2ca97e7044f7f@postgresql.org
Discussion: https://postgr.es/m/7d72ab20-c725-3ce2-f99d-4e64dd8a0de6@enterprisedb.com M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/path/joinrels.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
Defend against leaks into RelationBuildPartitionDesc.
commit : 2455ab48844c90419714e27eafd235a85de23232
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 14 Mar 2019 12:03:31 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 14 Mar 2019 12:03:31 -0400 In normal builds, this isn't very important, because the leaks go
into fairly short-lived contexts, but under CLOBBER_CACHE_ALWAYS,
this can result in leaking hundreds of megabytes into MessageContext,
which probably explains recent failures on hyrax.
This may or may not be the best long-term strategy for dealing
with this leak, but we can change it later if we come up with
something better. For now, do this to make the buildfarm green
again (hopefully). Commit 898e5e3290a72d288923260143930fb32036c00c
seems to have exacerbated this problem for reasons that are not
quite clear, but I don't believe it's actually the cause.
Discussion: http://postgr.es/m/CA+TgmoY3bRmGB6-DUnoVy5fJoreiBJ43rwMrQRCdPXuKt4Ykaw@mail.gmail.com M src/backend/partitioning/partdesc.c
Refactor ParamListInfo initialization
commit : c6ff0b892c30122b75d32c524109d16ee3c973f0
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 13:30:09 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 13:30:09 +0100 There were six copies of identical nontrivial code. Put it into a
function. M src/backend/commands/prepare.c
M src/backend/executor/functions.c
M src/backend/executor/spi.c
M src/backend/nodes/params.c
M src/backend/tcop/postgres.c
M src/include/nodes/params.h
M src/pl/plpgsql/src/pl_exec.c
Fix volatile vs. pointer confusion
commit : 1226d932b4dadc39ba2f9a488e4d784443ea6a78
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 08:25:25 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 14 Mar 2019 08:25:25 +0100 Variables used after a longjmp() need to be declared volatile. In
case of a pointer, it's the pointer itself that needs to be declared
volatile, not the pointed-to value. So we need
PyObject *volatile items;
instead of
volatile PyObject *items; /* wrong */
Discussion: https://www.postgresql.org/message-id/flat/f747368d-9e1a-c46a-ac76-3c27da32e8e4%402ndquadrant.com M contrib/hstore_plpython/hstore_plpython.c
M contrib/jsonb_plpython/jsonb_plpython.c
Fix thinko when bumping on temporary directories in pg_checksums
commit : 6eebfdc38b173edcd179f422cf7083383edb24bc
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 14 Mar 2019 14:14:49 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 14 Mar 2019 14:14:49 +0900 This fixes an oversight from 5c99513. This has no actual consequence as
PG_TEMP_FILE_PREFIX and PG_TEMP_FILES_DIR have the same value so when
bumping on a temporary path the directory scan was still moving on to
the next entry instead of skipping the rest of the scan, but let's keep
the logic correct.
Author: Michael Banck
Reviewed-by: Kyotaro Horiguchi
Discussion: https://postgr.es/m/20190314.115417.58230569.horiguchi.kyotaro@lab.ntt.co.jp
Backpatch-through: 11 M src/bin/pg_checksums/pg_checksums.c
Sync commentary in transam.h and bki.sgml.
commit : 401b87a24fbab7bfb48eb48050a51e033452ac6e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Mar 2019 00:23:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 14 Mar 2019 00:23:33 -0400 Commit a6417078c missed updating some comments in transam.h about
reservation of high OIDs for development purposes. Also tamp down
an over-optimistic comment there about how easy it'd be to change
FirstNormalObjectId.
Earlier, commit 09568ec3d failed to update bki.sgml for the split
between genbki.pl-assigned OIDs and those assigned during initdb.
Also fix genbki.pl so that it will complain if it overruns
that split. It's possible that doing so would have no very bad
consequences, but that's no excuse for not detecting it. M doc/src/sgml/bki.sgml
M src/backend/catalog/genbki.pl
M src/include/access/transam.h
Fix race condition in recently-added TAP test for recovery consistency
commit : 364298be22090769da14aa749fe730cf16ed3c2c
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 14 Mar 2019 12:41:45 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 14 Mar 2019 12:41:45 +0900 A couple of queries are run on the primary to create and fill in a test
table, which gets checked on the standby afterwards. However the test
was not waiting for the confirmation that the necessary records have
been replayed on the standby, leading to spurious failures.
Per buildfarm member loach. Thanks to Thomas Munro for the report and
Tom Lane for the failure analysis.
Discussion: https://postgr.es/m/CA+hUKGLUpqG52xtriUz5RpmeKPoEfNxNc-CginG+Cx+X2-Ycew@mail.gmail.com M src/test/recovery/t/016_min_consistency.pl
Adjust the tests for the hyperbolic functions.
commit : c015f853bf5958dd7562a17952df33a9d115e65f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Mar 2019 21:05:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Mar 2019 21:05:33 -0400 Preliminary results from the buildfarm suggest that no platform gets
commit c6f153dcf's test cases wrong by more than one or two units in
the last place, so setting extra_float_digits = 0 should be plenty
to hide the cross-platform variations.
Also, add tests for Infinity/NaN inputs. I think it highly likely
that we'll end up removing these again, rather than adding code to
make ancient platforms conform. But it seems useful to find out
just how many platforms have such issues before we make a decision.
Discussion: https://postgr.es/m/E1h3nUY-0000sM-Vf@gemulon.postgresql.org M src/test/regress/expected/float8.out
M src/test/regress/sql/float8.sql
Rethink how to test the hyperbolic functions.
commit : c6f153dcfebccf7a0d92290037793c656f1caef5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Mar 2019 18:13:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 13 Mar 2019 18:13:38 -0400 The initial commit tried to test them on trivial cases such as 0,
reasoning that we shouldn't hit any portability issues that way.
The buildfarm immediately proved that hope ill-founded, and anyway
it's not a great testing scheme because it doesn't prove that we're
even calling the right library function for each SQL function.
Instead, let's test them at inputs such as 1 (or something within
the valid range, as needed), so that each function should produce
a different output.
As committed, this is just about certain to show portability
failures, because it's very unlikely that every platform computes
these functions the same as mine down to the last bit. However,
I want to put it through a buildfarm cycle this way, so that
we can see how big the variations are. The plan is to add
"set extra_float_digits = -1", or whatever we need in order to
hide the variations; but first we need data.
Discussion: https://postgr.es/m/E1h3nUY-0000sM-Vf@gemulon.postgresql.org M src/test/regress/expected/float8.out
M src/test/regress/sql/float8.sql
Use condition variables to wait for checkpoints.
commit : c6c9474aafa4de357ae424cd18b69e8bf7a4babe
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 14 Mar 2019 10:25:27 +1300
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 14 Mar 2019 10:25:27 +1300 Previously we used a polling/sleeping loop to wait for checkpoints
to begin and end, which leads to up to a couple hundred milliseconds
of needless thumb-twiddling. Use condition variables instead.
Author: Thomas Munro
Reviewed-by: Andres Freund
Discussion: https://postgr.es/m/CA%2BhUKGLY7sDe%2Bbg1K%3DbnEzOofGoo4bJHYh9%2BcDCXJepb6DQmLw%40mail.gmail.com M doc/src/sgml/monitoring.sgml
M src/backend/postmaster/checkpointer.c
M src/backend/postmaster/pgstat.c
M src/include/pgstat.h
Revert setting client_min_messages to ‘debug1’ in new tests.
commit : 5655565c077c53b6e9b4b9bfcdf96439cf3af065
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 13 Mar 2019 13:14:42 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 13 Mar 2019 13:14:42 -0400 The buildfarm doesn't like this, because some buildfarm members have
log_statement = 'all'. We could change the log level of the messages
instead, but Tom doesn't like that. So let's do this instead, at
least for now.
Patch by Sergei Kornilov, applied here in reverse.
Discussion: http://postgr.es/m/2123251552490241@myt6-fe24916a5562.qloud-c.yandex.net M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Include all columns in default names for foreign key constraints
commit : f177660ab01e53dd5597b195dcc8526baa5cfcbd
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 13 Mar 2019 14:15:37 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 13 Mar 2019 14:15:37 +0100 When creating a name for a foreign key constraint when none is
specified, use all column names instead of only the first one, similar
to how it is already done for index names.
Author: Paul Martinez <hellopfm@gmail.com>
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/CAF+2_SFjky6XRfLNRXpkG97W6PRbOO_mjAxqXzAAimU=c7w7_A@mail.gmail.com M src/backend/commands/indexcmds.c
M src/backend/commands/statscmds.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/foreign_key.out
M src/test/regress/expected/rules.out
M src/test/regress/sql/foreign_key.sql
Allow ALTER TABLE .. SET NOT NULL to skip provably unnecessary scans.
commit : bbb96c3704c041d139181c6601e5bc770e045d26
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 13 Mar 2019 08:55:00 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 13 Mar 2019 08:55:00 -0400 If existing CHECK or NOT NULL constraints preclude the presence
of nulls, we need not look to see whether any are present.
Sergei Kornilov, reviewed by Stephen Frost, Ildar Musin, David Rowley,
and by me.
Discussion: http://postgr.es/m/81911511895540@web58j.yandex.ru M doc/src/sgml/ref/alter_table.sgml
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Remove extra comma
commit : 95fa9f1a137fcb55ed418d8c91a315c7bb169979
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 13 Mar 2019 13:41:14 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 13 Mar 2019 13:41:14 +0100 Author: Christoph Berg <myon@debian.org> M doc/src/sgml/pageinspect.sgml
Add TAP test to check consistency of minimum recovery LSN
commit : b0825d28ea83e44139bd319e6d1db2c499cd4c6a
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 13 Mar 2019 14:58:24 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 13 Mar 2019 14:58:24 +0900 c186ba13 has fixed an issue related to the updates of the minimum
recovery LSN across multiple processes on standbys, but we never really
had a test case able to reliably check its logic.
This commit introduces a new test case to close the gap, and is designed
to check the consistency of data based on the minimum recovery point set
by either the startup process or the checkpointer for both an offline
cluster (by looking at the on-disk page headers) and an online cluster
(using pageinspect).
Note that with c186ba13 reverted, this test fails badly for both the
online and offline cases, as designed.
Author: Michael Paquier, Andrew Gierth
Reviewed-by: Andrew Gierth, Georgios Kokolatos, Arthur Zakirov
Discussion: https://postgr.es/m/20181108044525.GA17482@paquier.xyz M src/test/perl/TestLib.pm
M src/test/recovery/Makefile
A src/test/recovery/t/016_min_consistency.pl
Rename pg_verify_checksums to pg_checksums
commit : 6dd263cfaa8447470af4fae3f61c47438f91d71f
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 13 Mar 2019 10:43:20 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 13 Mar 2019 10:43:20 +0900 The current tool name is too restrictive and focuses only on verifying
checksums. As more options to control checksums for an offline cluster
are planned to be added, switch to a more generic name. Documentation
as well as all past references to the tool are updated.
Author: Michael Paquier
Reviewed-by: Michael Banck, Fabien Coelho, Seigei Kornilov
Discussion: https://postgr.es/m/20181221201616.GD4974@nighthawk.caipicrew.dd-dns.de M doc/src/sgml/ref/allfiles.sgml
R079 doc/src/sgml/ref/pg_verify_checksums.sgml doc/src/sgml/ref/pg_checksums.sgml
M doc/src/sgml/reference.sgml
M src/backend/replication/basebackup.c
M src/bin/Makefile
M src/bin/initdb/t/001_initdb.pl
A src/bin/pg_checksums/.gitignore
R053 src/bin/pg_verify_checksums/Makefile src/bin/pg_checksums/Makefile
A src/bin/pg_checksums/nls.mk
R094 src/bin/pg_verify_checksums/pg_verify_checksums.c src/bin/pg_checksums/pg_checksums.c
A src/bin/pg_checksums/t/001_basic.pl
R089 src/bin/pg_verify_checksums/t/002_actions.pl src/bin/pg_checksums/t/002_actions.pl
D src/bin/pg_verify_checksums/.gitignore
D src/bin/pg_verify_checksums/nls.mk
D src/bin/pg_verify_checksums/t/001_basic.pl
Fix cross-version compatibility checks of pg_verify_checksums
commit : c9ae7f704c6772a99a456ed50d226c1fdf23f6d7
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 13 Mar 2019 09:51:02 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 13 Mar 2019 09:51:02 +0900 pg_verify_checksums performs a read of the control file, and the data it
fetches should be from a data folder compatible with the major version
of Postgres the binary has been compiled with, but we never actually
checked that compatibility.
Reported-by: Sergei Kornilov
Author: Michael Paquier
Reviewed-by: Sergei Kornilov
Discussion: https://postgr.es/m/155231347133.16480.11453587097036807558.pgcf@coridan.postgresql.org
Backpatch-through: 11 M src/bin/pg_verify_checksums/pg_verify_checksums.c
Correct obsolete nbtree page split comment.
commit : 3f34283973a342aa1cb709d6e8f5cea430efcf29
author : Peter Geoghegan <pg@bowt.ie>
date : Tue, 12 Mar 2019 16:40:05 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Tue, 12 Mar 2019 16:40:05 -0700 Commit 40dae7ec537, which made the nbtree page split algorithm more
robust, made _bt_insert_parent() only unlock the right child of the
parent page before inserting a new downlink into the parent. Update a
comment from the Berkeley days claiming that both left and right child
pages are unlocked before the new downlink actually gets inserted.
The claim that it is okay to release both locks early based on Lehman
and Yao's say-so never made much sense. Lehman and Yao must sometimes
"couple" buffer locks across a pair of internal pages when relocating a
downlink, unlike the corresponding code within _bt_getstack(). M src/backend/access/nbtree/nbtinsert.c
Add support for hyperbolic functions, as well as log10().
commit : f1d85aa98ee71d9662309f6f0384b2f7f8f16f02
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Mar 2019 15:55:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Mar 2019 15:55:09 -0400 The SQL:2016 standard adds support for the hyperbolic functions
sinh(), cosh(), and tanh(). POSIX has long required libm to
provide those functions as well as their inverses asinh(),
acosh(), atanh(). Hence, let's just expose the libm functions
to the SQL level. As with the trig functions, we only implement
versions for float8, not numeric.
For the moment, we'll assume that all platforms actually do have
these functions; if experience teaches otherwise, some autoconf
effort may be needed.
SQL:2016 also adds support for base-10 logarithm, but with the
function name log10(), whereas the name we've long used is log().
Add aliases named log10() for the float8 and numeric versions.
Lætitia Avrot
Discussion: https://postgr.es/m/CAB_COdguG22LO=rnxDQ2DW1uzv8aQoUzyDQNJjrR4k00XSgm5w@mail.gmail.com M doc/src/sgml/func.sgml
M src/backend/utils/adt/float.c
M src/include/catalog/catversion.h
M src/include/catalog/pg_proc.dat
M src/test/regress/expected/float8.out
M src/test/regress/sql/float8.sql
Remove remaining hard-wired OID references in the initial catalog data.
commit : 3aa0395d4ed36f040f20da304c122b956529dd14
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Mar 2019 12:30:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Mar 2019 12:30:35 -0400 In the v11-era commits that taught genbki.pl to resolve symbolic
OID references in the initial catalog data, we didn't bother to
make every last reference symbolic; some of the catalogs have so
few initial rows that it didn't seem worthwhile.
However, the new project policy that OIDs assigned by new patches
should be automatically renumberable changes this calculus.
A patch that wants to add a row in one of these catalogs would have
a problem when the OID it assigns gets renumbered. Hence, do the
mop-up work needed to make all OID references in initial data be
symbolic, and establish an associated project policy that we'll
never again write a hard-wired OID reference there.
No catversion bump since the contents of postgres.bki aren't
actually changed by this commit.
Discussion: https://postgr.es/m/CAH2-WzmMTGMcPuph4OvsO7Ykut0AOCF_i-=eaochT0dd2BN9CQ@mail.gmail.com M doc/src/sgml/bki.sgml
M src/backend/catalog/genbki.pl
M src/include/catalog/pg_class.dat
M src/include/catalog/pg_class.h
M src/include/catalog/pg_database.dat
M src/include/catalog/pg_database.h
M src/include/catalog/pg_proc.dat
M src/include/catalog/pg_ts_config.dat
M src/include/catalog/pg_ts_config.h
M src/include/catalog/pg_ts_config_map.dat
M src/include/catalog/pg_ts_config_map.h
M src/include/catalog/pg_ts_dict.dat
M src/include/catalog/pg_ts_dict.h
M src/include/catalog/pg_type.dat
M src/include/catalog/pg_type.h
Create a script that can renumber manually-assigned OIDs.
commit : a6417078c4140e51cfd717448430f274b449d687
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Mar 2019 10:50:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 12 Mar 2019 10:50:48 -0400 This commit adds a Perl script renumber_oids.pl, which can reassign a
range of manually-assigned OIDs to someplace else by modifying OID
fields of the catalog *.dat files and OID-assigning macros in the
catalog *.h files.
Up to now, we've encouraged new patches that need manually-assigned
OIDs to use OIDs just above the range of existing OIDs. Predictably,
this leads to patches stepping on each others' toes, as whichever
one gets committed first creates an OID conflict that other patch
author(s) have to resolve manually. With the availability of
renumber_oids.pl, we can eliminate a lot of this hassle.
The new project policy, therefore, is:
* Encourage new patches to use high OIDs (the documentation suggests
choosing a block of OIDs at random in 8000..9999).
* After feature freeze in each development cycle, run renumber_oids.pl
to move all such OIDs down to lower numbers, thus freeing the high OID
range for the next development cycle.
This plan should greatly reduce the risk of OID collisions between
concurrently-developed patches. Also, if such a collision happens
anyway, we have the option to resolve it without much effort by doing
an off-schedule OID renumbering to get the first-committed patch out
of the way. Or a patch author could use renumber_oids.pl to change
their patch's assignments without much pain.
This approach does put a premium on not hard-wiring any OID values
in places where renumber_oids.pl and genbki.pl can't fix them.
Project practice in that respect seems to be pretty good already,
but a follow-on patch will sand down some rough edges.
John Naylor and Tom Lane, per an idea of Peter Geoghegan's
Discussion: https://postgr.es/m/CAH2-WzmMTGMcPuph4OvsO7Ykut0AOCF_i-=eaochT0dd2BN9CQ@mail.gmail.com M doc/src/sgml/bki.sgml
M src/backend/catalog/Catalog.pm
M src/include/catalog/indexing.h
A src/include/catalog/renumber_oids.pl
M src/include/catalog/toasting.h
M src/tools/RELEASE_CHANGES
Fix testing of parallel-safety of scan/join target.
commit : b5afdde6a7bb777d399b20da6fb8a664a1cd2784
author : Etsuro Fujita <efujita@postgresql.org>
date : Tue, 12 Mar 2019 16:21:57 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Tue, 12 Mar 2019 16:21:57 +0900 In commit 960df2a971 ("Correctly assess parallel-safety of tlists when
SRFs are used."), the testing of scan/join target was done incorrectly,
which caused a plan-quality problem. Backpatch through to v11 where
the aforementioned commit went in, since this is a regression from v10.
Author: Etsuro Fujita
Reviewed-by: Robert Haas and Tom Lane
Discussion: https://postgr.es/m/5C75303E.8020303@lab.ntt.co.jp M src/backend/optimizer/plan/planner.c
Add more tests for FSM.
commit : 6f918159a97acf76ee2512e44f5ed5dcaaa0d923
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 12 Mar 2019 08:14:28 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 12 Mar 2019 08:14:28 +0530 In commit b0eaa4c51bb, we left out a test that used a vacuum to remove dead
rows as the behavior of test was not predictable. This test has been
rewritten to use fillfactor instead to control free space. Since we no
longer need to remove dead rows as part of the test, put the fsm regression
test in a parallel group.
Author: John Naylor
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/CAA4eK1L=qWp_bJ5aTc9+fy4Ewx2LPaLWY-RbR4a60g_rupCKnQ@mail.gmail.com M src/test/regress/expected/fsm.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/fsm.sql
Add routine able to update the control file to src/common/
commit : ce6afc6823fbe2d83a5a77061b05864612b6bab2
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 12 Mar 2019 10:03:33 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 12 Mar 2019 10:03:33 +0900 This adds a new routine to src/common/ which is compatible with both the
frontend and backend code, able to update the control file's contents.
This is now getting used only by pg_rewind, but some upcoming patches
which add more control on checksums for offline instances will make use
of it. This could also get used more by the backend as xlog.c has its
own flavor of the same logic with some wait events and an additional
flush phase before closing the opened file descriptor, but this is let
as separate work.
Author: Michael Banck, Michael Paquier
Reviewed-by: Fabien Coelho, Sergei Kornilov
Discussion: https://postgr.es/m/20181221201616.GD4974@nighthawk.caipicrew.dd-dns.de M src/bin/pg_rewind/pg_rewind.c
M src/common/controldata_utils.c
M src/include/common/controldata_utils.h
Allow fractional input values for integer GUCs, and improve rounding logic.
commit : 1a83a80a2fe5b559f85ed4830acb92d5124b7a9a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Mar 2019 19:13:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Mar 2019 19:13:46 -0400 Historically guc.c has just refused examples like set work_mem = '30.1GB',
but it seems more useful for it to take that and round off the value to
some reasonable approximation of what the user said. Just rounding to
the parameter's native unit would work, but it would lead to rather
silly-looking settings, such as 31562138kB for this example. Instead
let's round to the nearest multiple of the next smaller unit (if any),
producing 30822MB.
Also, do the units conversion math in floating point and round to integer
(if needed) only at the end. This produces saner results for inputs that
aren't exact multiples of the parameter's native unit, and removes another
difference in the behavior for integer vs. float parameters.
In passing, document the ability to use hex or octal input where it
ought to be documented.
Discussion: https://postgr.es/m/1798.1552165479@sss.pgh.pa.us M doc/src/sgml/config.sgml
M src/backend/utils/misc/guc.c
M src/test/regress/expected/reloptions.out
M src/test/regress/sql/reloptions.sql
Tweak wording on VARIADIC array doc patch.
commit : fe0b2c12c992fa44ca0448bde9099957306c843f
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 11 Mar 2019 18:23:01 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 11 Mar 2019 18:23:01 -0400 Per suggestion from Tom Lane. M doc/src/sgml/func.sgml
Document incompatibility of comparison expressions with VARIADIC array arguments
commit : 5e74a427854fa17babfbb0e22c4ca95e4f48f2fe
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 11 Mar 2019 18:14:05 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 11 Mar 2019 18:14:05 -0400 COALESCE, GREATEST and LEAST all look like functions taking variable
numbers of arguments, but in fact they are not functions, and so
VARIADIC array arguments don't work with them. Add a note to the docs
explaining this fact.
The consensus is not to try to make this work, but just to document the
limitation.
Discussion: https://postgr.es/m/CAFj8pRCaAtuXuRtvXf5GmPbAVriUQrNMo7-=TXUFN025S31R_w@mail.gmail.com M doc/src/sgml/func.sgml
Remove spurious return.
commit : 32b8f0b0332ef96c67f06ded4d458a3ce12fe2ef
author : Andres Freund <andres@anarazel.de>
date : Mon, 11 Mar 2019 15:03:27 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 11 Mar 2019 15:03:27 -0700 Per buildfarm member anole.
Author: Andres Freund M src/include/access/tableam.h
Give up on testing guc.c’s behavior for “infinity” inputs.
commit : d9c5e9629bf511a51328fd083ee452de88d91d9d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Mar 2019 17:53:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Mar 2019 17:53:09 -0400 Further buildfarm testing shows that on the machines that are failing
ac75959cd's test case, what we're actually getting from strtod("-infinity")
is a syntax error (endptr == value) not ERANGE at all. This test case
is not worth carrying two sets of expected output for, so just remove it,
and revert commit b212245f9's misguided attempt to work around the platform
dependency.
Discussion: https://postgr.es/m/E1h33xk-0001Og-Gs@gemulon.postgresql.org M src/backend/utils/misc/guc.c
M src/test/regress/expected/guc.out
M src/test/regress/sql/guc.sql
Ensure sufficient alignment for ParallelTableScanDescData in BTShared.
commit : 8cacea7a725103f1a037a5ee06112ebe31051c66
author : Andres Freund <andres@anarazel.de>
date : Mon, 11 Mar 2019 14:26:43 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 11 Mar 2019 14:26:43 -0700 Previously ParallelTableScanDescData was just a member in BTShared,
but after c2fe139c2 that doesn't guarantee sufficient alignment as
specific AMs might (are likely to) need atomic variables in the
struct.
One might think that MAXALIGNing would be sufficient, but as a
comment in shm_toc_allocate() explains, that's not enough. For now,
copy the hack described there.
For parallel sequential scans no such change is needed, as its
allocations go through shm_toc_allocate().
An alternative approach would have been to allocate the parallel scan
descriptor in a separate TOC entry, but there seems little benefit in
doing so.
Per buildfarm member dromedary.
Author: Andres Freund
Discussion: https://postgr.es/m/20190311203126.ty5gbfz42gjbm6i6@alap3.anarazel.de M src/backend/access/nbtree/nbtsort.c
tableam: Add and use scan APIs.
commit : c2fe139c201c48f1133e9fbea2dd99b8efe2fadd
author : Andres Freund <andres@anarazel.de>
date : Mon, 11 Mar 2019 12:46:41 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 11 Mar 2019 12:46:41 -0700 Too allow table accesses to be not directly dependent on heap, several
new abstractions are needed. Specifically:
1) Heap scans need to be generalized into table scans. Do this by
introducing TableScanDesc, which will be the "base class" for
individual AMs. This contains the AM independent fields from
HeapScanDesc.
The previous heap_{beginscan,rescan,endscan} et al. have been
replaced with a table_ version.
There's no direct replacement for heap_getnext(), as that returned
a HeapTuple, which is undesirable for a other AMs. Instead there's
table_scan_getnextslot(). But note that heap_getnext() lives on,
it's still used widely to access catalog tables.
This is achieved by new scan_begin, scan_end, scan_rescan,
scan_getnextslot callbacks.
2) The portion of parallel scans that's shared between backends need
to be able to do so without the user doing per-AM work. To achieve
that new parallelscan_{estimate, initialize, reinitialize}
callbacks are introduced, which operate on a new
ParallelTableScanDesc, which again can be subclassed by AMs.
As it is likely that several AMs are going to be block oriented,
block oriented callbacks that can be shared between such AMs are
provided and used by heap. table_block_parallelscan_{estimate,
intiialize, reinitialize} as callbacks, and
table_block_parallelscan_{nextpage, init} for use in AMs. These
operate on a ParallelBlockTableScanDesc.
3) Index scans need to be able to access tables to return a tuple, and
there needs to be state across individual accesses to the heap to
store state like buffers. That's now handled by introducing a
sort-of-scan IndexFetchTable, which again is intended to be
subclassed by individual AMs (for heap IndexFetchHeap).
The relevant callbacks for an AM are index_fetch_{end, begin,
reset} to create the necessary state, and index_fetch_tuple to
retrieve an indexed tuple. Note that index_fetch_tuple
implementations need to be smarter than just blindly fetching the
tuples for AMs that have optimizations similar to heap's HOT - the
currently alive tuple in the update chain needs to be fetched if
appropriate.
Similar to table_scan_getnextslot(), it's undesirable to continue
to return HeapTuples. Thus index_fetch_heap (might want to rename
that later) now accepts a slot as an argument. Core code doesn't
have a lot of call sites performing index scans without going
through the systable_* API (in contrast to loads of heap_getnext
calls and working directly with HeapTuples).
Index scans now store the result of a search in
IndexScanDesc->xs_heaptid, rather than xs_ctup->t_self. As the
target is not generally a HeapTuple anymore that seems cleaner.
To be able to sensible adapt code to use the above, two further
callbacks have been introduced:
a) slot_callbacks returns a TupleTableSlotOps* suitable for creating
slots capable of holding a tuple of the AMs
type. table_slot_callbacks() and table_slot_create() are based
upon that, but have additional logic to deal with views, foreign
tables, etc.
While this change could have been done separately, nearly all the
call sites that needed to be adapted for the rest of this commit
also would have been needed to be adapted for
table_slot_callbacks(), making separation not worthwhile.
b) tuple_satisfies_snapshot checks whether the tuple in a slot is
currently visible according to a snapshot. That's required as a few
places now don't have a buffer + HeapTuple around, but a
slot (which in heap's case internally has that information).
Additionally a few infrastructure changes were needed:
I) SysScanDesc, as used by systable_{beginscan, getnext} et al. now
internally uses a slot to keep track of tuples. While
systable_getnext() still returns HeapTuples, and will so for the
foreseeable future, the index API (see 1) above) now only deals with
slots.
The remainder, and largest part, of this commit is then adjusting all
scans in postgres to use the new APIs.
Author: Andres Freund, Haribabu Kommi, Alvaro Herrera
Discussion:
https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql M contrib/amcheck/verify_nbtree.c
M contrib/pgrowlocks/pgrowlocks.c
M contrib/pgstattuple/pgstattuple.c
M contrib/tsm_system_rows/tsm_system_rows.c
M contrib/tsm_system_time/tsm_system_time.c
M src/backend/access/gist/gistget.c
M src/backend/access/hash/hashsearch.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/index/genam.c
M src/backend/access/index/indexam.c
M src/backend/access/nbtree/nbtree.c
M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/spgist/spgscan.c
M src/backend/access/table/tableam.c
M src/backend/access/table/tableamapi.c
M src/backend/access/tablesample/system.c
M src/backend/bootstrap/bootstrap.c
M src/backend/catalog/aclchk.c
M src/backend/catalog/index.c
M src/backend/catalog/pg_conversion.c
M src/backend/catalog/pg_db_role_setting.c
M src/backend/catalog/pg_publication.c
M src/backend/catalog/pg_subscription.c
M src/backend/commands/cluster.c
M src/backend/commands/constraint.c
M src/backend/commands/copy.c
M src/backend/commands/dbcommands.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/commands/tablespace.c
M src/backend/commands/typecmds.c
M src/backend/commands/vacuum.c
M src/backend/executor/execCurrent.c
M src/backend/executor/execIndexing.c
M src/backend/executor/execMain.c
M src/backend/executor/execPartition.c
M src/backend/executor/execReplication.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeBitmapHeapscan.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/executor/nodeIndexscan.c
M src/backend/executor/nodeModifyTable.c
M src/backend/executor/nodeSamplescan.c
M src/backend/executor/nodeSeqscan.c
M src/backend/executor/nodeTidscan.c
M src/backend/partitioning/partbounds.c
M src/backend/postmaster/autovacuum.c
M src/backend/postmaster/pgstat.c
M src/backend/replication/logical/launcher.c
M src/backend/replication/logical/worker.c
M src/backend/rewrite/rewriteDefine.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/adt/selfuncs.c
M src/backend/utils/init/postinit.c
M src/include/access/genam.h
M src/include/access/heapam.h
M src/include/access/relscan.h
M src/include/access/tableam.h
M src/include/catalog/index.h
M src/include/nodes/execnodes.h
M src/tools/pgindent/typedefs.list
pgbench: increase the maximum number of variables/arguments
commit : a47841528107921f02c280e0c5f91c5a1d86adb0
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 11 Mar 2019 11:47:35 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 11 Mar 2019 11:47:35 -0400 pgbench's arbitrary limit of 10 arguments for SQL statements or
metacommands is far too low. Increase it to 256.
This results in a very modest increase in memory usage, not enough to
worry about.
The maximum includes the SQL statement or metacommand. This is reflected
in the comments and revised TAP tests.
Simon Riggs and Dagfinn Ilmari Mannsåker with some light editing by me.
Reviewed by: David Rowley and Fabien Coelho
Discussion: https://postgr.es/m/CANP8+jJiMJOAf-dLoHuR-8GENiK+eHTY=Omw38Qx7j2g0NDTXA@mail.gmail.com M doc/src/sgml/ref/pgbench.sgml
M src/bin/pgbench/pgbench.c
M src/bin/pgbench/t/001_pgbench_with_server.pl
Fix typos in commit 8586bf7ed8.
commit : a6e48da08844eeb5a72c8b59dad3aaab6e891fac
author : Amit Kapila <akapila@postgresql.org>
date : Mon, 11 Mar 2019 08:16:14 +0530
committer: Andres Freund <andres@anarazel.de>
date : Mon, 11 Mar 2019 08:16:14 +0530 Author: Amit Kapila
Discussion: https://postgr.es/m/CAA4eK1KNv1Mg2krf4E9ssWFnE=8A9mZ1VbVywXBZTFSzb+wP2g@mail.gmail.com M src/backend/access/table/tableamapi.c
M src/backend/utils/cache/relcache.c
M src/include/access/tableam.h
Move hash_any prototype from access/hash.h to utils/hashutils.h
commit : af38498d4c9b840e0e454574519459edda3871db
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 11 Mar 2019 13:17:50 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 11 Mar 2019 13:17:50 -0300 ... as well as its implementation from backend/access/hash/hashfunc.c to
backend/utils/hash/hashfn.c.
access/hash is the place for the hash index AM, not really appropriate
for generic facilities, which is what hash_any is; having things the old
way meant that anything using hash_any had to include the AM's include
file, pointlessly polluting its namespace with unrelated, unnecessary
cruft.
Also move the HTEqual strategy number to access/stratnum.h from
access/hash.h.
To avoid breaking third-party extension code, add an #include
"utils/hashutils.h" to access/hash.h. (An easily removed line by
committers who enjoy their asbestos suits to protect them from angry
extension authors.)
Discussion: https://postgr.es/m/201901251935.ser5e4h6djt2@alvherre.pgsql M contrib/citext/citext.c
M contrib/hstore/hstore_op.c
M contrib/pg_stat_statements/pg_stat_statements.c
M contrib/sepgsql/uavc.c
M src/backend/access/common/tupdesc.c
M src/backend/access/hash/hashfunc.c
M src/backend/access/tablesample/bernoulli.c
M src/backend/access/tablesample/system.c
M src/backend/catalog/pg_publication.c
M src/backend/commands/publicationcmds.c
M src/backend/executor/execGrouping.c
M src/backend/executor/nodeSamplescan.c
M src/backend/lib/bloomfilter.c
M src/backend/nodes/bitmapset.c
M src/backend/storage/file/sharedfileset.c
M src/backend/tsearch/ts_typanalyze.c
M src/backend/utils/adt/acl.c
M src/backend/utils/adt/arrayfuncs.c
M src/backend/utils/adt/date.c
M src/backend/utils/adt/jsonb_gin.c
M src/backend/utils/adt/jsonb_util.c
M src/backend/utils/adt/mac.c
M src/backend/utils/adt/mac8.c
M src/backend/utils/adt/network.c
M src/backend/utils/adt/numeric.c
M src/backend/utils/adt/pg_lsn.c
M src/backend/utils/adt/rangetypes.c
M src/backend/utils/adt/tid.c
M src/backend/utils/adt/timestamp.c
M src/backend/utils/adt/uuid.c
M src/backend/utils/adt/varchar.c
M src/backend/utils/adt/varlena.c
M src/backend/utils/cache/catcache.c
M src/backend/utils/cache/relcache.c
M src/backend/utils/hash/hashfn.c
M src/backend/utils/resowner/resowner.c
M src/backend/utils/sort/tuplesort.c
M src/include/access/hash.h
M src/include/access/stratnum.h
M src/include/utils/hashutils.h
In guc.c, ignore ERANGE errors from strtod().
commit : b212245f96437b574b59993c772e4d9276965e49
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Mar 2019 11:25:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Mar 2019 11:25:23 -0400 Instead, just proceed with the infinity or zero result that it should
return for overflow/underflow. This avoids a platform dependency,
in that various versions of strtod are inconsistent about whether they
signal ERANGE for a value that's specified as infinity.
It's possible this won't be enough to remove the buildfarm failures
we're seeing from ac75959cd, in which case I'll take out the infinity
test case that commit added. But first let's see if we can fix it.
Discussion: https://postgr.es/m/E1h33xk-0001Og-Gs@gemulon.postgresql.org M src/backend/utils/misc/guc.c
Fix potential memory access violation in ecpg if filename of include file is shorter than 2 characters.
commit : 08cecfaf60c484f219ba7e6ee23e9699aea4e9af
author : Michael Meskes <meskes@postgresql.org>
date : Mon, 11 Mar 2019 16:11:16 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Mon, 11 Mar 2019 16:11:16 +0100 Patch by: "Wu, Fei" <wufei.fnst@cn.fujitsu.com> M src/interfaces/ecpg/preproc/pgc.l
Fix ecpglib regression that made it impossible to close a cursor that was opened in a prepared statement.
commit : 98bdaab0d918169a36d64a06667a809c673ec065
author : Michael Meskes <meskes@postgresql.org>
date : Mon, 11 Mar 2019 16:00:13 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Mon, 11 Mar 2019 16:00:13 +0100 Patch by: "Kuroda, Hayato" <kuroda.hayato@jp.fujitsu.com> M src/interfaces/ecpg/ecpglib/cursor.c
Remove unused macro
commit : 3c067154471100ae691d1a7b2659ee439ab7b96d
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 11 Mar 2019 09:29:50 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 11 Mar 2019 09:29:50 +0100 Use was removed in 25ca5a9a54923a5d6746f771c4c23e85a195bde5. M src/backend/utils/adt/tsvector_op.c
psql: Add documentation URL to \help output
commit : 27f3dea64833d68c1fa08c1e5d26176a579f69c8
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 11 Mar 2019 08:50:02 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 11 Mar 2019 08:50:02 +0100 Add a link to the specific command's reference web page to the bottom
of its \help output.
Discussion: https://www.postgresql.org/message-id/flat/40179bd0-fa7d-4108-1991-a20ae9ad5667%402ndquadrant.com M src/bin/psql/create_help.pl
M src/bin/psql/help.c
Adjust error message for partial writes in WAL segments
commit : f2d84a4a6b4ec891a0a52f583ed5aa081c71acc6
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 11 Mar 2019 09:31:25 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 11 Mar 2019 09:31:25 +0900 93473c6 has removed openLogOff, changing on the way the error message
which is used to report partial writes to WAL segments. The
newly-introduced error message used the offset up to which the write has
happened, keeping always the same total length to write. This changes
the error message so as the number of bytes left to write are reported.
Reported-by: Michael Paquier
Author: Robert Haas
Discussion: https://postgr.es/m/20190306235251.GA17293@paquier.xyz M src/backend/access/transam/xlog.c
Fix documentation on partitioning vs. foreign tables
commit : fc84c05acd151cb1141c47d4af0c5ca803a4c3b4
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 10 Mar 2019 19:45:29 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 10 Mar 2019 19:45:29 -0300 1. The PARTITION OF clause of CREATE FOREIGN TABLE was not explained in
the CREATE FOREIGN TABLE reference page. Add it.
(Postgres 10 onwards)
2. The limitation that tuple routing cannot target partitions that are
foreign tables was not documented clearly enough. Improve wording.
(Postgres 10 onwards)
3. The UPDATE tuple re-routing concurrency behavior was explained in
the DDL chapter, which doesn't seem the right place. Move it to the
UPDATE reference page instead. (Postgres 11 onwards).
Authors: Amit Langote, David Rowley.
Reviewed-by: Etsuro Fujita.
Reported-by: Derek Hans
Discussion: https://postgr.es/m/CAGrP7a3Xc1Qy_B2WJcgAD8uQTS_NDcJn06O5mtS_Ne1nYhBsyw@mail.gmail.com M doc/src/sgml/ddl.sgml
M doc/src/sgml/ref/create_foreign_table.sgml
M doc/src/sgml/ref/update.sgml
Reduce the default value of autovacuum_vacuum_cost_delay to 2ms.
commit : cbccac371c79d96c44fcd8c9cbb5ff4dedaaa522
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Mar 2019 15:16:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Mar 2019 15:16:21 -0400 This is a better way to implement the desired change of increasing
autovacuum's default resource consumption.
Discussion: https://postgr.es/m/28720.1552101086@sss.pgh.pa.us M doc/src/sgml/config.sgml
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
Revert “Increase the default vacuum_cost_limit from 200 to 2000”
commit : 52985e4fea75f1ec742742f27e246a8775c99e08
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Mar 2019 15:05:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Mar 2019 15:05:25 -0400 This reverts commit bd09503e633b8077822bb4daf91625b71ac16253.
Per discussion, it seems like what we should do instead is to
reduce the default value of autovacuum_vacuum_cost_delay by the
same factor. That's functionally equivalent as long as the
platform can accurately service the smaller delay request, which
should be true on anything released in the last 10 years or more.
And smaller, more-closely-spaced delays are better in terms of
providing a steady I/O load.
Discussion: https://postgr.es/m/28720.1552101086@sss.pgh.pa.us M doc/src/sgml/config.sgml
M src/backend/utils/init/globals.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
Convert [autovacuum_]vacuum_cost_delay into floating-point GUCs.
commit : caf626b2cd471615914986f18282c03c8282a1f4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Mar 2019 15:01:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 10 Mar 2019 15:01:39 -0400 This change makes it possible to specify sub-millisecond delays,
which work well on most modern platforms, though that was not true
when the cost-delay feature was designed.
To support this without breaking existing configuration entries,
improve guc.c to allow floating-point GUCs to have units. Also,
allow "us" (microseconds) as an input/outpu