Peter Eisentraut [Fri, 10 Jul 2020 14:51:29 +0000 (16:51 +0200)]
Add missing <application> tags in application doc <refentrytitle>s
Most of them already have this, but some were missing.
Author: Author: Dagfinn Ilmari Mannsåker <ilmari@ilmari.org>
Discussion: https://www.postgresql.org/message-id/flat/87o8pco34z.fsf%40wibble.ilmari.org
Michael Paquier [Fri, 10 Jul 2020 08:08:13 +0000 (17:08 +0900)]
Revert "Remove reset of testtablespace from pg_regress on Windows"
This reverts commit
2b2a070, that moved the reset of path
"testtablespace" used by the regression tests as a path for tablespaces
(via --outputdir) from pg_regress to the MSVC script vcregress.pl, as
this broke the behavior added by
ce5d342 to be able to safely run the
regression test suite with an administrative Windows account using a
restricted token.
Note that before
2b2a070, the code doing the reset in pg_regress.c
included a comment telling that we had better move that out to a
different place, leading to the mistake done in
2b2a070. Fix this
comment, and document instead that we had better never remove this code,
for the sake of not breaking again the behavior we expect on Windows.
Thanks to Thomas Munro and Andrew Dunstan for the discussion.
Discussion: https://postgr.es/m/
6d9eee97-54c8-e14a-48f7-
3194e712f54f@2ndQuadrant.com
Discussion: https://postgr.es/m/CA+hUKGLiieEzfrdWxWFE+_wnXho_F5Smx972X1wEubhS7v1q9g@mail.gmail.com
Peter Eisentraut [Fri, 10 Jul 2020 06:27:00 +0000 (08:27 +0200)]
Log the location field before any backtrace
This order makes more sense because the location is effectively at the
lowest level of the backtrace.
Discussion: https://www.postgresql.org/message-id/flat/
90f5fa04-c410-a54e-9449-
aa3749fb7972%402ndquadrant.com
Alvaro Herrera [Fri, 10 Jul 2020 00:13:25 +0000 (20:13 -0400)]
Remove WARNING message from brin_desummarize_range
This message was being emitted on the grounds that only crashed
summarization could cause it, but in reality even an aborted vacuum
could do it ... which makes it way too noisy, particularly since it
shows up in regression tests and makes them die.
Reported by Tom Lane.
Discussion: https://postgr.es/m/489091.
1593534251@sss.pgh.pa.us
Tom Lane [Thu, 9 Jul 2020 20:02:23 +0000 (16:02 -0400)]
Fix pg_current_logfile() to not emit a carriage return on Windows.
Due to not having our signals straight about CRLF vs. LF line
termination, the output of pg_current_logfile() included a trailing
\r on Windows. To fix, force the file descriptor it uses into text
mode.
While here, move a couple of local variable declarations to make
the function's logic clearer.
In v12 and v13, also back-patch the test added by
1c4e88e2f so that
this function has some test coverage. However, the 004_logrotate.pl
test script doesn't exist before v12, and it didn't seem worth adding
to older branches just for this.
Per report from Thomas Kellerer. Back-patch to v10 where this
function was added.
Discussion: https://postgr.es/m/
412ae8da-76bb-640f-039a-
f3513499e53d@gmx.net
Tom Lane [Thu, 9 Jul 2020 15:37:21 +0000 (11:37 -0400)]
Further tighten Windows CRLF conversion in our TAP test scripts.
Buildfarm results now imply that Perl's IPC::Run does CRLF conversion
for us if we're using native Perl, but not when using MSys Perl.
Restrict the conversions done by PostgresNode.pm to act only in the
latter case. (Similar conversions done in TestLib.pm and RewindTest.pm
were already handled this way.)
Discussion: https://postgr.es/m/
412ae8da-76bb-640f-039a-
f3513499e53d@gmx.net
Peter Eisentraut [Thu, 9 Jul 2020 07:47:43 +0000 (09:47 +0200)]
pg_dump: Further reorganize getTableAttrs()
After further discussion after
daa9fe8a5264a3f192efa5ddee8fb011ad9da365, reorder the version-specific
sections from oldest to newest. Also, remove the variable assignments
from PQfnumber() to reduce vertical space.
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
Discussion: https://www.postgresql.org/message-id/flat/
6594334b-40fd-14f1-6bc5-
877afa3feed5@2ndquadrant.com
Fujii Masao [Thu, 9 Jul 2020 04:31:33 +0000 (13:31 +0900)]
doc: Correct the description about the length of pg_stat_activity.query.
pg_stat_activity.query text is truncated at 1024 bytes. But previously
the document described that it's truncated at 1024 characters.
This was not accurate when considering multibyte characters.
Back-patch to v10 where this inaccurate description was added.
Author: Atsushi Torikoshi
Reviewed-by: Daniel Gustafsson, Fujii Masao
Discussion: https://postgr.es/m/
cd5b49a5a14e887542f5f569c1c6bde2@oss.nttdata.com
Tom Lane [Thu, 9 Jul 2020 00:25:52 +0000 (20:25 -0400)]
Tighten up Windows CRLF conversion in our TAP test scripts.
The previous approach was to search-and-destroy all \r occurrences
no matter what. That seems more likely to hide bugs than anything
else; indeed it seems to be hiding one now. Fix things so that
we only transform \r\n to \n.
Side effects: must do this before, not after, chomp'ing if we're
going to chomp, else we'd fail to clean up a trailing \r\n. Also,
remove safe_psql's redundant repetition of what psql already did;
else it might reduce \r\r\n to \n, which is exactly the scenario
I'm hoping to expose.
Perhaps this should be back-patched, but for now I'm content to
see what happens in HEAD.
Discussion: https://postgr.es/m/
412ae8da-76bb-640f-039a-
f3513499e53d@gmx.net
David Rowley [Wed, 8 Jul 2020 22:06:24 +0000 (10:06 +1200)]
Fix whitespace in HashAgg EXPLAIN ANALYZE
The Sort node does not put a space between the number of kilobytes and
the "kB" of memory or disk space used, but HashAgg does. Here we align
HashAgg to do the same as Sort. Sort has been displaying this
information for longer than HashAgg, so it makes sense to align HashAgg
to Sort rather than the other way around.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/
20200708163021.GW4107@telsasoft.com
Backpatch-through: 13, where the hashagg started showing these details
Andres Freund [Mon, 15 Jun 2020 17:14:40 +0000 (10:14 -0700)]
code: replace most remaining uses of 'master'.
Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/
20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
Andres Freund [Mon, 15 Jun 2020 17:19:32 +0000 (10:19 -0700)]
docs: replace 'master process' with 'supervisor process' where appropriate.
Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/
20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
Andres Freund [Mon, 15 Jun 2020 17:18:41 +0000 (10:18 -0700)]
docs: replace 'master' with 'root' where appropriate.
These uses of 'master' refer to partitioning / inheritance. 'root'
seems more descriptive than 'master'.
Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/
20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
Andres Freund [Mon, 15 Jun 2020 17:12:58 +0000 (10:12 -0700)]
docs: replace 'master' with 'primary' where appropriate.
Also changed "in the primary" to "on the primary", and added a few
"the" before "primary".
Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/
20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
Andres Freund [Sun, 14 Jun 2020 21:22:47 +0000 (14:22 -0700)]
code: replace 'master' with 'leader' where appropriate.
Leader already is the more widely used terminology, but a few places
didn't get the message.
Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/
20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
Andres Freund [Sun, 14 Jun 2020 21:05:18 +0000 (14:05 -0700)]
code: replace 'master' with 'primary' where appropriate.
Also changed "in the primary" to "on the primary", and added a few
"the" before "primary".
Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/
20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
Andres Freund [Sun, 14 Jun 2020 18:47:37 +0000 (11:47 -0700)]
tap tests: replace 'master' with 'primary'.
We've largely replaced master with primary in docs etc, but tap test
still widely used master.
Author: Andres Freund
Reviewed-By: David Steele
Discussion: https://postgr.es/m/
20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
Alvaro Herrera [Wed, 8 Jul 2020 18:52:39 +0000 (14:52 -0400)]
Don't treat DumpOptions->dump_inserts like a boolean
This has been an integer count since
7e413a0f82c8 so treat it explicitly
like an integer.
No backpatch since this is just cosmetic.
Tom Lane [Wed, 8 Jul 2020 17:41:52 +0000 (13:41 -0400)]
Add test coverage for pg_current_logfile() function.
There has been no coverage at all up to now. Given Thomas Kellerer's
recent report, I suspect this may fail on (some?) Windows machines,
but let's find out.
Discussion: https://postgr.es/m/
412ae8da-76bb-640f-039a-
f3513499e53d@gmx.net
Fujii Masao [Wed, 8 Jul 2020 12:24:34 +0000 (21:24 +0900)]
Fix incorrect variable datatype.
Since slot_keep_segs indicates the number of WAL segments not LSN,
its datatype should not be XLogRecPtr.
Back-patch to v13 where this issue was added.
Reported-by: Atsushi Torikoshi
Author: Atsushi Torikoshi, tweaked by Fujii Masao
Discussion: https://postgr.es/m/
ebd0d674f3e050222238a960cac5251a@oss.nttdata.com
Peter Eisentraut [Wed, 8 Jul 2020 09:17:52 +0000 (11:17 +0200)]
Remove junk in test file
Remove a redundant and failing command, probably a typo.
Magnus Hagander [Wed, 8 Jul 2020 08:11:43 +0000 (10:11 +0200)]
Fix typo
Author: Daniel Gustafsson
Fujii Masao [Wed, 8 Jul 2020 02:00:23 +0000 (11:00 +0900)]
Fix function name in comment.
Author: Masahiro Ikeda
Discussion: https://postgr.es/m/
0043eee90b38351ea199d7e3294c10c4@oss.nttdata.com
Michael Paquier [Wed, 8 Jul 2020 01:41:53 +0000 (10:41 +0900)]
doc: Fix inconsistencies in GIN, BRIN and SP-GiST for optional opclass methods
The GIN and SP-GiST parts were out-of-sync since the changes of
14903f2,
and the BRIN part was wrong since its introduction in
15cb2bd.
Author: Guillaume Lelarge
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/CAECtzeXKvEPEr967h0PRYRi39uTmdEms=oUtc_PWGjZRNN1prw@mail.gmail.com
Backpatch-through: 13
Tom Lane [Tue, 7 Jul 2020 22:10:42 +0000 (18:10 -0400)]
Un-break pg_upgrade from pre-v12 servers.
I neglected to test this scenario while preparing commit
f3faf35f3,
so of course it was broken, thanks to some very obscure and undocumented
code in pg_dump. Pre-v12 databases might have toast tables attached to
partitioned tables, which we need to ignore since newer servers never
create such useless toast tables. There was a filter for this case in
binary_upgrade_set_type_oids_by_rel_oid(), which appeared to just
prevent the pg_type OID from being copied. But actually it managed to
prevent the toast table from being created at all --- or it did before
I took out that logic. But that was a fundamentally bizarre place to be
making the test in the first place. The place where the filter should
have been, one would think, is binary_upgrade_set_pg_class_oids(), so
add it there.
While at it, reorganize binary_upgrade_set_pg_class_oids() so that it
doesn't make a completely useless query when it knows it's being
invoked for an index. And correct a comment that mis-described the
scenario where we need to force creation of a TOAST table.
Per buildfarm.
Tom Lane [Tue, 7 Jul 2020 19:43:22 +0000 (15:43 -0400)]
Don't create pg_type entries for sequences or toast tables.
Commit
f7f70d5e2 left one inconsistency behind: we're still creating
pg_type entries for the composite types of sequences and toast tables,
but not arrays over those composites. But there seems precious little
reason to have named composite types for toast tables, and not much more
to have them for sequences (especially given the thought that sequences
may someday not be standalone relations at all).
So, let's close that inconsistency by removing these composite types,
rather than adding arrays for them. This buys back a little bit of
the initial pg_type bloat added by the previous patch, and could be
a significant savings in a large database with many toast tables.
Aside from a small logic rearrangement in heap_create_with_catalog,
this patch mostly needs to clean up some places that were assuming that
pg_class.reltype always has a valid value. Those are really pre-existing
bugs, given that it's documented otherwise; notably, the plpgsql changes
fix code that gives "cache lookup failed for type 0" on indexes today.
But none of these seem interesting enough to back-patch.
Also, remove the pg_dump/pg_upgrade infrastructure for propagating
a toast table's pg_type OID into the new database, since we no longer
need that.
Discussion: https://postgr.es/m/
761F1389-C6A8-4C15-80CE-
950C961F5341@gmail.com
Alvaro Herrera [Tue, 7 Jul 2020 17:08:00 +0000 (13:08 -0400)]
Morph pg_replication_slots.min_safe_lsn to safe_wal_size
The previous definition of the column was almost universally disliked,
so provide this updated definition which is more useful for monitoring
purposes: a large positive value is good, while zero or a negative value
means danger. This should be operationally more convenient.
Backpatch to 13, where the new column to pg_replication_slots (and the
feature it represents) were added.
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reported-by: Fujii Masao <masao.fujii@oss.nttdata.com>
Discussion: https://postgr.es/m/
9ddfbf8c-2f67-904d-44ed-
cf8bc5916228@oss.nttdata.com
Magnus Hagander [Tue, 7 Jul 2020 14:57:27 +0000 (16:57 +0200)]
Check ssl_in_use flag when reporting statistics
Previously we checked that the ssl pointer was not null, but this puts a
requirement on there being such a pointer which may not be true in
future multi-ssl-library supporting times. This seems to have been an
oversight in
9029f4b3740, but hasn't really had any effect since we only
have one library.
Author: Daniel Gustafsson
Peter Eisentraut [Tue, 7 Jul 2020 08:21:54 +0000 (10:21 +0200)]
Resolve gratuitous tabs in test SQL file
Peter Geoghegan [Mon, 6 Jul 2020 20:47:29 +0000 (13:47 -0700)]
Remove unnecessary PageIsEmpty() nbtree build check.
nbtree index builds cannot write out an empty page. That would mean
that there was no way to create a pivot tuple pointing to the page one
level up, since _bt_truncate() generates one based on page's firstright
tuple.
Replace the unnecessary PageIsEmpty() check with an assertion that
checks that the page has space for at least two line pointers (the
would-be high key line pointer, plus at least one valid "data item"
tuple line pointer).
The PageIsEmpty() check was added by commit
5d9f146c over 20 years ago.
It looks like it has always been unnecessary.
Tom Lane [Mon, 6 Jul 2020 18:21:16 +0000 (14:21 -0400)]
Create composite array types for initdb-created relations.
When we invented arrays of composite types (commit
bc8036fc6),
we excluded system catalogs, basically just on the grounds of not
wanting to bloat pg_type. However, it's definitely inconsistent that
catalogs' composite types can't be put into arrays when others can.
Another problem is that the exclusion is done by checking
IsUnderPostmaster in heap_create_with_catalog, which means that
(1) If a user tries to create a table in single-user mode, it doesn't
get an array type. That's bad in itself, plus it breaks pg_upgrade.
(2) If someone drops and recreates a system view or information_schema
view (as we occasionally recommend doing), it will now have an array
type where it did not before, making for still more inconsistency.
So this is all pretty messy. Let's just get rid of the inconsistency
and decree that system-created relations should have array types if
similar user-created ones would, i.e. it only depends on the relkind.
As of HEAD, that means that the initial contents of pg_type grow from
411 rows to 605, which is a lot of growth percentage-wise, but it's
still quite a small catalog compared to others.
Wenjing Zeng, reviewed by Shawn Wang, further hacking by me
Discussion: https://postgr.es/m/
761F1389-C6A8-4C15-80CE-
950C961F5341@gmail.com
Peter Eisentraut [Mon, 6 Jul 2020 07:53:37 +0000 (09:53 +0200)]
Fix typo in test
The test was supposed to error but didn't. Apparently, a copy and
paste and string replace mistake from a nearby similar test.
Fujii Masao [Mon, 6 Jul 2020 05:27:09 +0000 (14:27 +0900)]
doc: Add note about possible performance overhead by enabling track_planning.
Enabling pg_stat_statements.track_plaanning may incur a noticeable
performance penalty, especially when a fewer kinds of queries are executed
on many concurrent connections. This commit documents this note.
Back-patch to v13 where pg_stat_statements.track_plaanning was added.
Suggested-by: Pavel Stehule
Author: Fujii Masao
Reviewed-by: Pavel Stehule
Discussion: https://postgr.es/m/CAFj8pRC9Jxa8r5i0TNBWLb8mzuaYzEoLq3QOvip0jVpHPOLbVA@mail.gmail.com
Michael Paquier [Mon, 6 Jul 2020 04:06:08 +0000 (13:06 +0900)]
Refactor routines for name lookups of procedures and operators
This introduces a new set of extended routines for procedure and
operator name lookups, with a flag bitmask argument that can modify the
result. The following options are available:
- Force schema qualification, ignoring search_path. This is similar to
the existing option for format_{operator|procedure}_qualified().
- Force NULL as result instead of a numeric OID for an undefined
object. This option is new.
This is a refactoring similar to
1185c78, that will be used for a future
patch to improve the SQL functions providing information using object
addresses for undefined objects.
Author: Michael Paquier
Reviewed-by: Aleksander Alekseev, Dmitry Dolgov, Daniel Gustafsson,
Álvaro Herrera
Discussion: https://postgr.es/m/CAB7nPqSZxrSmdHK-rny7z8mi=EAFXJ5J-0RbzDw6aus=wB5azQ@mail.gmail.com
Amit Kapila [Mon, 6 Jul 2020 03:14:33 +0000 (08:44 +0530)]
Remove extra whitespace in comments atop ReorderBufferCheckMemoryLimit.
Backpatch-through: 13, where it was introduced
Michael Paquier [Mon, 6 Jul 2020 03:12:11 +0000 (12:12 +0900)]
Add new flag to format_type_extended() to get NULL for undefined type
If a type scanned is undefined, type format routines have two behaviors
depending on if FORMAT_TYPE_ALLOW_INVALID is used by the caller or not:
- Issue a cache lookup error
- Return an undefined type name "???", "???[]" or "-"
The current interface is not really helpful for callers willing to
format properly a type name, but still make sure that the type is
defined as there could be types matching the strings generated when
looking for an undefined type, even if that should not be a problem in
practice. In order to counter that, add a new flag called
FORMAT_TYPE_INVALID_AS_NULL that returns a NULL result instead of "???
or "-" which does not generate an error. This flag will be used in a
follow-up patch improving the set of SQL functions showing information
for object addresses when it comes to undefined objects.
Author: Michael Paquier
Reviewed-by: Aleksander Alekseev, Dmitry Dolgov, Daniel Gustafsson,
Álvaro Herrera
Discussion: https://postgr.es/m/CAB7nPqSZxrSmdHK-rny7z8mi=EAFXJ5J-0RbzDw6aus=wB5azQ@mail.gmail.com
Amit Kapila [Mon, 6 Jul 2020 02:51:52 +0000 (08:21 +0530)]
Remove unused function parameter in end_parallel_vacuum.
Author: Vignesh C
Reviewed-by: Sawada Masahiko
Backpatch-through: 13, where it was introduced
Discussion: https://postgr.es/m/CALDaNm3Ppt71NafGY5mk3V2i3Q+mm93pVibDq-0NpW7WU67Jcg@mail.gmail.com
Michael Paquier [Mon, 6 Jul 2020 00:16:17 +0000 (09:16 +0900)]
Improve perl script in MSVC to build binaries
This commit includes two improvements for build.pl in src/tools/msvc/:
- Fix two warnings related to $ARGV[0] being uninitialized, something
that happens when calling build.pl (or build.bat) without arguments to
compile all the components with a release quality.
- If calling the script with more than two arguments, exit immediately
and show a new help output. build.pl was not failing in this case
before this commit, and the extra arguments were just ignored, but the
new behavior helps in understanding how to run the script without
looking at the documentation for the Windows builds.
Reported-by: Ranier Vilela
Author: Michael Paquier
Reviewed-by: Juan José Santamaría Flecha, David Zhang
Discussion: https://postgr.es/m/CAEudQAo38dfR_0Ugt2OHy4mq-6Hz93XPSBAGEUV67RhKdgp8Zg@mail.gmail.com
Tom Lane [Sun, 5 Jul 2020 17:12:31 +0000 (13:12 -0400)]
Inline the fast path of plpgsql's exec_cast_value().
In the common case where this function isn't actually asked to perform
any type conversion, there's nothing it has to do beyond comparing the
arguments. Arrange for that part to be inlined into callers, with the
slower path remaining out-of-line. This seems to be good for several
percent speedup on simple cases, with only minimal code bloat.
Amit Khandekar
Discussion: https://postgr.es/m/CAJ3gD9eBNrmUD7WBBLG8ohaZ485H9y+4eihQTgr+K8Lhka3vcQ@mail.gmail.com
Peter Eisentraut [Sun, 5 Jul 2020 13:37:57 +0000 (15:37 +0200)]
doc: Spell checking
Michael Paquier [Sun, 5 Jul 2020 10:35:56 +0000 (19:35 +0900)]
doc: Fix incorrect reference to textout in plpgsql examples
This error has survived for 22 years, and has been introduced by
da63386.
Reported-by: Erwin Brandstetter
Discussion: https://postgr.es/m/CAGHENJ57wogGOvGXo5LgWYcqswxafLck8ELqHDR+zrkTPgs_OQ@mail.gmail.com
Backpatch-through: 9.5
Peter Eisentraut [Sun, 5 Jul 2020 09:41:52 +0000 (11:41 +0200)]
Rename enable_incrementalsort for clarity
Author: James Coleman <jtc331@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/
df652910-e985-9547-152c-
9d4357dc3979%402ndquadrant.com
Joe Conway [Sat, 4 Jul 2020 17:46:31 +0000 (13:46 -0400)]
Fix "ignoring return value" complaints from commit
96d1f423f9
The cfbot and some BF animals are complaining about the previous
read_binary_file commit because of ignoring return value of ‘fread’.
So let's make everyone happy by testing the return value even though
not strictly needed.
Reported by Justin Pryzby, and suggested patch by Tom Lane. Backpatched
to v11 same as the previous commit.
Reported-By: Justin Pryzby
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/flat/
969b8d82-5bb2-5fa8-4eb1-
f0e685c5d736%40joeconway.com
Backpatch-through: 11
Joe Conway [Sat, 4 Jul 2020 10:26:53 +0000 (06:26 -0400)]
Read until EOF vice stat-reported size in read_binary_file
read_binary_file(), used by SQL functions pg_read_file() and friends,
uses stat to determine file length to read, when not passed an explicit
length as an argument. This is problematic, for example, if the file
being read is a virtual file with a stat-reported length of zero.
Arrange to read until EOF, or StringInfo data string lenth limit, is
reached instead.
Original complaint and patch by me, with significant review, corrections,
advice, and code optimizations by Tom Lane. Backpatched to v11. Prior to
that only paths relative to the data and log dirs were allowed for files,
so no "zero length" files were reachable anyway.
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/flat/
969b8d82-5bb2-5fa8-4eb1-
f0e685c5d736%40joeconway.com
Backpatch-through: 11
Tom Lane [Fri, 3 Jul 2020 23:01:21 +0000 (19:01 -0400)]
Clamp total-tuples estimates for foreign tables to ensure planner sanity.
After running GetForeignRelSize for a foreign table, adjust rel->tuples
to be at least as large as rel->rows. This prevents bizarre behavior
in estimate_num_groups() and perhaps other places, especially in the
scenario where rel->tuples is zero because pg_class.reltuples is
(suggesting that ANALYZE has never been run for the table). As things
stood, we'd end up estimating one group out of any GROUP BY on such a
table, whereas the default group-count estimate is more likely to result
in a sane plan.
Also, clarify in the documentation that GetForeignRelSize has the option
to override the rel->tuples value if it has a better idea of what to use
than what is in pg_class.reltuples.
Per report from Jeff Janes. Back-patch to all supported branches.
Patch by me; thanks to Etsuro Fujita for review
Discussion: https://postgr.es/m/CAMkU=1xNo9cnan+Npxgz0eK7394xmjmKg-QEm8wYG9P5-CcaqQ@mail.gmail.com
Tom Lane [Fri, 3 Jul 2020 21:01:34 +0000 (17:01 -0400)]
Fix temporary tablespaces for shared filesets some more.
Commit
ecd9e9f0b fixed the problem in the wrong place, causing unwanted
side-effects on the behavior of GetNextTempTableSpace(). Instead,
let's make SharedFileSetInit() responsible for subbing in the value
of MyDatabaseTableSpace when the default tablespace is called for.
The convention about what is in the tempTableSpaces[] array is
evidently insufficiently documented, so try to improve that.
It also looks like SharedFileSetInit() is doing the wrong thing in the
case where temp_tablespaces is empty. It was hard-wiring use of the
pg_default tablespace, but it seems like using MyDatabaseTableSpace
is more consistent with what happens for other temp files.
Back-patch the reversion of PrepareTempTablespaces()'s behavior to
9.5, as
ecd9e9f0b was. The changes in SharedFileSetInit() go back
to v11 where that was introduced. (Note there is net zero code change
before v11 from these two patch sets, so nothing to release-note.)
Magnus Hagander and Tom Lane
Discussion: https://postgr.es/m/CABUevExg5YEsOvqMxrjoNvb3ApVyH+9jggWGKwTDFyFCVWczGQ@mail.gmail.com
Tom Lane [Fri, 3 Jul 2020 19:42:10 +0000 (15:42 -0400)]
Inline plpgsql's exec_stmt() into exec_stmts().
This saves one level of C function call per plpgsql statement executed,
and permits a tiny additional optimization of not saving and restoring
estate->err_stmt for each statement in a block. The net effect seems
nearly un-measurable on x86_64, but there's a clear win on aarch64,
amounting to two or three percent in a loop over a few simple plpgsql
statements.
To do this, we have to get rid of the other existing call sites for
exec_stmt(). Replace them with exec_toplevel_block(), which is just
defined to do what exec_stmts() does, but for a single
PLpgSQL_stmt_block statement. Hard-wiring the expectation of which
statement type applies here allows us to skip the dispatch switch,
making this not much uglier than the previous factorization.
Amit Khandekar, tweaked a bit by me
Discussion: https://postgr.es/m/CAJ3gD9eBNrmUD7WBBLG8ohaZ485H9y+4eihQTgr+K8Lhka3vcQ@mail.gmail.com
Magnus Hagander [Fri, 3 Jul 2020 13:09:06 +0000 (15:09 +0200)]
Fix temporary tablespaces for shared filesets
A likely copy/paste error in
98e8b480532 from back in 2004 would
cause temp tablespace to be reset to InvalidOid if temp_tablespaces
was set to the same value as the primary tablespace in the database.
This would cause shared filesets (such as for parallel hash joins)
to ignore them, putting the temporary files in the default tablespace
instead of the configured one. The bug is in the old code, but it
appears to have been exposed only once we had shared filesets.
Reviewed-By: Daniel Gustafsson
Discussion: https://postgr.es/m/CABUevExg5YEsOvqMxrjoNvb3ApVyH+9jggWGKwTDFyFCVWczGQ@mail.gmail.com
Backpatch-through: 9.5
Fujii Masao [Fri, 3 Jul 2020 03:08:35 +0000 (12:08 +0900)]
doc: Correct description of restart_lsn in pg_replication_slots
Previously the document explained that restart_lsn indicates the LSN of
oldest WAL won't be automatically removed during checkpoints. But
since v13 this was no longer true thanks to max_slot_wal_keep_size.
Back-patch to v13 where max_slot_wal_keep_size was added.
Author: Fujii Masao
Discussion: https://postgr.es/m/
6497f1e9-3148-c5da-7e49-
b2fddad9a42f@oss.nttdata.com
Fujii Masao [Fri, 3 Jul 2020 02:35:22 +0000 (11:35 +0900)]
Change default of pg_stat_statements.track_planning to off.
Since v13 pg_stat_statements is allowed to track the planning time of
statements when track_planning option is enabled. Its default was on.
But this feature could cause more terrible spinlock contentions in
pg_stat_statements. As a result of this, Robins Tharakan reported that
v13 beta1 showed ~45% performance drop at high DB connection counts
(when compared with v12.3) during fully-cached SELECT-only test using
pgbench.
To avoid this performance regression by the default setting,
this commit changes default of pg_stat_statements.track_planning to off.
Back-patch to v13 where pg_stat_statements.track_planning was introduced.
Reported-by: Robins Tharakan
Author: Fujii Masao
Reviewed-by: Julien Rouhaud
Discussion: https://postgr.es/m/
2895b53b033c47ccb22972b589050dd9@EX13D05UWC001.ant.amazon.com
Peter Geoghegan [Thu, 2 Jul 2020 23:34:54 +0000 (16:34 -0700)]
Initialize work_mem using current guc.c default.
Do the same for the maintenance_work_mem global variable.
Oversight in commit
848ae330a49, which increased the previous defaults
for work_mem and maintenance_work_mem by 4X.
Peter Geoghegan [Thu, 2 Jul 2020 21:54:55 +0000 (14:54 -0700)]
nbtree: Rename _bt_search() variables.
Make some of the variable names in _bt_search() consistent with
corresponding variables within _bt_getstackbuf(). This naming scheme is
clearer because the variable names always express a relationship between
the currently locked buffer/page and some other page.
Michael Paquier [Thu, 2 Jul 2020 04:57:03 +0000 (13:57 +0900)]
Move description of libpqwalreceiver hooks out of the replication's README
src/backend/replication/README includes since
32bc08b a basic
description of the WAL receiver hooks available in walreceiver.h for a
module like libpqwalreceiver, but the README has never been updated to
reflect changes done to the hooks, so the contents of the README have
rotten with the time. This commit moves the description from the README
to walreceiver.h, where it will be hard to miss that a description
update or addition is needed depending on the modifications done to the
hooks.
Each hook now includes a description of what it does in walreceiver.h,
and the replication's README mentions walreceiver.h.
Thanks also to Amit Kapila for the discussion.
Author: Michael Paquier
Reviewed-by: Peter Eisentraut
Discussion: https://postgr.es/m/
20200502024606.GA471944@paquier.xyz
Michael Paquier [Wed, 1 Jul 2020 08:03:50 +0000 (17:03 +0900)]
Refactor ObjectAddress field assignments in more places
This is a follow-up commit similar to
68de144, with more places in the
backend code simplified with the macros able to assign values to the
fields of ObjectAddress. The code paths changed here could be
transitioned later into using more grouping when inserting dependency
records, simplifying this future work.
Author: Daniel Gustafsson, Michael Paquier
Discussion: https://postgr.es/m/
20190213182737.mxn6hkdxwrzgxk35@alap3.anarazel.de
Amit Kapila [Wed, 1 Jul 2020 02:28:36 +0000 (07:58 +0530)]
Improve vacuum error context handling.
Use separate functions to save and restore error context information as
that made code easier to understand. Also, make it clear that the index
information required for error context is sane.
Author: Andres Freund, Justin Pryzby, Amit Kapila
Backpatch-through: 13, where it was introduced
Discussion: https://postgr.es/m/CAA4eK1LWo+v1OWu=Sky27GTGSCuOmr7iaURNbc5xz6jO+SaPeA@mail.gmail.com
Michael Paquier [Wed, 1 Jul 2020 02:12:33 +0000 (11:12 +0900)]
Refactor creation of normal dependency records when creating extension
When creating an extension, the same type of dependency is used when
registering a dependency to a schema and required extensions. This
improves the code so as those dependencies are not recorded one-by-one,
but grouped together. Note that this has as side effect to remove
duplicate dependency entries, even if it should not happen in practice
as extensions listed as required in a control file should be listed only
once.
Extracted from a larger patch by the same author.
Author: Daniel Dustafsson
Discussion: https://postgr.es/m/
20200629065535.GA183079@paquier.xyz
Michael Paquier [Wed, 1 Jul 2020 01:47:24 +0000 (10:47 +0900)]
Fix removal of files generated by TAP tests for SSL
001_ssltests.pl and 002_scram.pl both generated an extra file for a
client key used in the tests that were not removed. In Debian, this
causes repeated builds to fail.
The code refactoring done in
4dc6355 broke the cleanup done in
001_ssltests.pl, and the new tests added in 002_scram.pl via
d6e612f
forgot the removal of one file. While on it, fix a second issue
introduced in 002_scram.pl where we use the same file name in 001 and
002 for the temporary client key whose permissions are changed in the
test, as using the same file name in both tests could cause failures
with parallel jobs of src/test/ssl/ if one test removes a file still
needed by the second test.
Reported-by: Felix Lechner
Author: Daniel Gustafsson, Felix Lechner
Reviewed-by: Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/CAFHYt543sjX=Cm_aEeoejStyP47C+Y3+Wh6WbirLXsgUMaw7iw@mail.gmail.com
Backpatch-through: 13
David Rowley [Wed, 1 Jul 2020 00:15:59 +0000 (12:15 +1200)]
Further adjustments to Hashagg EXPLAIN ANALYZE output
The "Disk Usage" and "HashAgg Batches" properties in the EXPLAIN ANALYZE
output for HashAgg were previously only shown if the number of batches
was greater than 0. Here we change this so that these properties are
always shown for EXPLAIN ANALYZE formats other than "text". The idea here
is that since the HashAgg could have spilled to disk if there had been
more data or groups to aggregate, then it's relevant that we're clear in
the EXPLAIN ANALYZE output when no spilling occurred in this particular
execution of the given plan.
For the "text" EXPLAIN format, we still hide these properties when no
spilling occurs. This EXPLAIN format is designed to be easy for humans
to read. To maintain the readability we have a higher threshold for which
properties we display for this format.
Discussion: https://postgr.es/m/CAApHDvo_dmNozQQTmN-2jGp1vT%3Ddxx7Q0vd%2BMvD1cGpv2HU%3DSg%40mail.gmail.com
Backpatch-through: 13, where the hashagg spilling code was added.
Michael Meskes [Tue, 30 Jun 2020 15:31:08 +0000 (17:31 +0200)]
Fix ecpg crash with bytea and cursor variables.
Author: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
Bruce Momjian [Tue, 30 Jun 2020 16:26:51 +0000 (12:26 -0400)]
doc: clarify that storage parameter values are optional
In a few cases, the documented syntax specified storage parameter values
as required.
Reported-by: galiev_mr@taximaxim.ru
Discussion: https://postgr.es/m/
159283163235.684.
4482737698910467437@wrigleys.postgresql.org
Backpatch-through: 9.5
Bruce Momjian [Tue, 30 Jun 2020 15:55:53 +0000 (11:55 -0400)]
doc: change pg_upgrade wal_level to be not minimal
Previously it was specified to be only replica.
Discussion: https://postgr.es/m/
20200618180058.GK7349@momjian.us
Backpatch-through: 9.5
Fujii Masao [Tue, 30 Jun 2020 14:55:07 +0000 (23:55 +0900)]
Add +(pg_lsn,numeric) and -(pg_lsn,numeric) operators.
By using these operators, the number of bytes can be added into and
subtracted from LSN.
Bump catalog version.
Author: Fujii Masao
Reviewed-by: Kyotaro Horiguchi, Michael Paquier, Asif Rehman
Discussion: https://postgr.es/m/
ed9f7f74-e996-67f8-554a-
52ebd3779b3b@oss.nttdata.com
Michael Paquier [Tue, 30 Jun 2020 04:26:11 +0000 (13:26 +0900)]
Prevent compilation of frontend-only files in src/common/ with backend
Any frontend-only file of src/common/ should include a protection to
prevent such code to be included in the backend compilation.
fe_memutils.c and restricted_token.c have been doing that, while
file_utils.c (since
bf5bb2e) and logging.c (since
fc9a62a) forgot it.
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/
20200625080757.GI130132@paquier.xyz
Peter Eisentraut [Mon, 29 Jun 2020 22:29:35 +0000 (00:29 +0200)]
pgstattuple: Have pgstattuple_approx accept TOAST tables
TOAST tables have a visibility map and a free space map, so they can
be supported by pgstattuple_approx just fine.
Add test cases to show how various pgstattuple functions accept TOAST
tables. Also add similar tests to pg_visibility, which already
accepted TOAST tables correctly but had no test coverage for them.
Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at>
Discussion: https://www.postgresql.org/message-id/flat/
27c4496a-02b9-dc87-8f6f-
bddbef54e0fe@2ndquadrant.com
Tom Lane [Mon, 29 Jun 2020 22:55:01 +0000 (18:55 -0400)]
Remove support for timezone "posixrules" file.
The IANA tzcode library has a feature to read a time zone file named
"posixrules" and apply the daylight-savings transition dates and times
therein, when it is given a POSIX-style time zone specification that
lacks an explicit transition rule. However, there's a problem with
that code: it doesn't work for dates past the Y2038 time_t rollover.
(Effectively, all times beyond that point are treated as standard
time.) The IANA crew regard this feature as legacy, so their plan is
to remove it not fix it. The time frame in which that will happen
is unclear, but presumably it'll happen well before 2038.
Moreover, effective with the next IANA data update (probably this
fall), the recommended default will be to not install a "posixrules"
file in the first place. The time frame in which tzdata packagers
might adopt that suggestion is likewise unclear, but at least some
platforms will probably do it in the next year or so. While we could
ignore that recommendation so far as PG-supplied tzdata trees are
concerned, builds using --with-system-tzdata will be subject to
whatever the platform's tzdata packager decides to do.
Thus, whether or not we do anything, some increasing fraction of
Postgres users will be exposed to the behavior observed when there
is no "posixrules" file; and if we do nothing, we'll have essentially
no control over the timing of that change.
The best thing to do to ameliorate the uncertainty seems to be to
proactively remove the posixrules-reading feature. If we do that in
a scheduled release then at least we can release-note the behavioral
change, rather than having users be surprised by it after a routine
tzdata update.
The change in question is fairly minor anyway: to be affected,
you have to be using a POSIX-style timezone spec, it has to not
have an explicit rule, and it has to not be one of the four traditional
continental-USA zone names (EST5EDT, CST6CDT, MST7MDT, or PST8PDT),
as those are special-cased. Since the default "posixrules" file
provides USA DST rules, the number of people who are likely to find
such a zone spec useful is probably quite small. Moreover, the
fallback behavior with no explicit rule and no "posixrules" file is to
apply current USA rules, so the only thing that really breaks is the
DST transitions in years before 2007 (and you get the countervailing
fix that transitions after 2038 will be applied).
Now, some installations might have replaced the "posixrules" file,
allowing e.g. EU rules to be applied to a POSIX-style timezone spec.
That won't work anymore. But it's not exactly clear why this solution
would be preferable to using a regular named zone. In any case, given
the Y2038 issue, we need to be pushing users to stop depending on this.
Back-patch into v13; it hasn't been released yet, so it seems OK to
change its behavior. (Personally I think we ought to back-patch
further, but I've been outvoted.)
Discussion: https://postgr.es/m/1390.
1562258309@sss.pgh.pa.us
Discussion: https://postgr.es/m/
20200621211855.6211-1-eggert@cs.ucla.edu
Tom Lane [Mon, 29 Jun 2020 21:12:38 +0000 (17:12 -0400)]
Mop up some no-longer-necessary hacks around printf %.*s format.
Commit
54cd4f045 added some kluges to work around an old glibc bug,
namely that %.*s could misbehave if glibc thought any characters in
the supplied string were incorrectly encoded. Now that we use our
own snprintf.c implementation, we need not worry about that bug (even
if it still exists in the wild). Revert a couple of particularly
ugly hacks, and remove or improve assorted comments.
Note that there can still be encoding-related hazards here: blindly
clipping at a fixed length risks producing wrongly-encoded output
if the clip splits a multibyte character. However, code that's
doing correct multibyte-aware clipping doesn't really need a comment
about that, while code that isn't needs an explanation why not,
rather than a red-herring comment about an obsolete bug.
Discussion: https://postgr.es/m/279428.
1593373684@sss.pgh.pa.us
Peter Geoghegan [Mon, 29 Jun 2020 19:30:39 +0000 (12:30 -0700)]
nbtree: Correct inaccurate split location comment.
Minor oversight in commit
fab25024338.
Tom Lane [Mon, 29 Jun 2020 15:41:19 +0000 (11:41 -0400)]
Avoid using %c printf format for potentially non-ASCII characters.
Since %c only passes a C "char" to printf, it's incapable of dealing
with multibyte characters. Passing just the first byte of such a
character leads to an output string that is visibly not correctly
encoded, resulting in undesirable behavior such as encoding conversion
failures while sending error messages to clients.
We've lived with this issue for a long time because it was inconvenient
to avoid in a portable fashion. However, now that we always use our own
snprintf code, it's reasonable to use the %.*s format to print just one
possibly-multibyte character in a string. (We previously avoided that
obvious-looking answer in order to work around glibc's bug #6530, cf
commits
54cd4f045 and
ed437e2b2.)
Hence, run around and fix a bunch of places that used %c to report
a character found in a user-supplied string. For simplicity, I did
not touch places that were emitting non-user-facing debug messages,
or reporting catalog data that should always be ASCII. (It's also
unclear how useful this approach could be in frontend code, where
it's less certain that we know what encoding we're dealing with.)
In passing, improve a couple of poorly-written error messages in
pageinspect/heapfuncs.c.
This is a longstanding issue, but I'm hesitant to back-patch because
of the impact on translatable message strings. In any case this fix
would not work reliably before v12.
Tom Lane and Quan Zongliang
Discussion: https://postgr.es/m/
a120087c-4c88-d9d4-1ec5-
808d7a7f133d@gmail.com
Peter Eisentraut [Mon, 29 Jun 2020 09:04:42 +0000 (11:04 +0200)]
Add current substring regular expression syntax
SQL:1999 had syntax
SUBSTRING(text FROM pattern FOR escapechar)
but this was replaced in SQL:2003 by the more clear
SUBSTRING(text SIMILAR pattern ESCAPE escapechar)
but this was never implemented in PostgreSQL. This patch adds that
new syntax as an alternative in the parser, and updates documentation
and tests to indicate that this is the preferred alternative now.
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>
Reviewed-by: Vik Fearing <vik@postgresfriends.org>
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
Discussion: https://www.postgresql.org/message-id/flat/
a15db31c-d0f8-8ce0-9039-
578a31758adb%402ndquadrant.com
Peter Eisentraut [Mon, 29 Jun 2020 08:36:52 +0000 (10:36 +0200)]
Clean up grammar a bit
Simplify the grammar specification of substring() and overlay() a bit,
simplify and update some comments.
Reviewed-by: Pavel Stehule <pavel.stehule@gmail.com>
Reviewed-by: Vik Fearing <vik@postgresfriends.org>
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
Discussion: https://www.postgresql.org/message-id/flat/
a15db31c-d0f8-8ce0-9039-
578a31758adb%402ndquadrant.com
Michael Paquier [Mon, 29 Jun 2020 00:56:52 +0000 (09:56 +0900)]
Refactor ObjectAddress field assignments for type dependencies
The logic used to build the set of dependencies needed for a type is
rather repetitive with direct assignments for each ObjectAddress field.
This refactors the code to use the macro ObjectAddressSet() instead, to
do the same work. There are more areas of the backend code that could
use this macro, but these are left for a follow-up patch that will
partially rework the way dependencies are recorded as well. Type
dependencies are left out of the follow-up patch, so they are refactored
separately here.
Extracted from a larger patch by the same author.
Author: Daniel Gustafsson
Discussion: https://potgr.es/m/
20190213182737.mxn6hkdxwrzgxk35@alap3.anarazel.de
Noah Misch [Sun, 28 Jun 2020 05:05:04 +0000 (22:05 -0700)]
Fix documentation of "must be vacuumed within" warning.
Warnings start 10M transactions before xidStopLimit, which is 11M
transactions before wraparound. The sample WARNING output showed a
value greater than 11M, and its HINT message predated commit
25ec228ef760eb91c094cc3b6dea7257cc22ffb5. Hence, the sample was
impossible. Back-patch to 9.5 (all supported versions).
Tom Lane [Sat, 27 Jun 2020 17:26:17 +0000 (13:26 -0400)]
Fix list of SSL error codes for older OpenSSL versions.
Apparently 1.0.1 lacks SSL_R_VERSION_TOO_HIGH and
SSL_R_VERSION_TOO_LOW. Per buildfarm.
Tom Lane [Sat, 27 Jun 2020 16:47:58 +0000 (12:47 -0400)]
Add hints about protocol-version-related SSL connection failures.
OpenSSL's native reports about problems related to protocol version
restrictions are pretty opaque and inconsistent. When we get an
SSL error that is plausibly due to this, emit a hint message that
includes the range of SSL protocol versions we (think we) are
allowing. This should at least get the user thinking in the right
direction to resolve the problem, even if the hint isn't totally
accurate, which it might not be for assorted reasons.
Back-patch to v13 where we increased the default minimum protocol
version, thereby increasing the risk of this class of failure.
Patch by me, reviewed by Daniel Gustafsson
Discussion: https://postgr.es/m/
a9408304-4381-a5af-d259-
e55d349ae4ce@2ndquadrant.com
Tom Lane [Sat, 27 Jun 2020 16:20:33 +0000 (12:20 -0400)]
Change libpq's default ssl_min_protocol_version to TLSv1.2.
When we initially created this parameter, in commit
ff8ca5fad, we left
the default as "allow any protocol version" on grounds of backwards
compatibility. However, that's inconsistent with the backend's default
since
b1abfec82; protocol versions prior to 1.2 are not considered very
secure; and OpenSSL has had TLSv1.2 support since 2012, so the number
of PG servers that need a lesser minimum is probably quite small.
On top of those things, it emerges that some popular distros (including
Debian and RHEL) set MinProtocol=TLSv1.2 in openssl.cnf. Thus, far
from having "allow any protocol version" behavior in practice, what
we actually have as things stand is a platform-dependent lower limit.
So, change our minds and set the min version to TLSv1.2. Anybody
wanting to connect with a new libpq to a pre-2012 server can either
set ssl_min_protocol_version=TLSv1 or accept the fallback to non-SSL.
Back-patch to v13 where the aforementioned patches appeared.
Patch by me, reviewed by Daniel Gustafsson
Discussion: https://postgr.es/m/
a9408304-4381-a5af-d259-
e55d349ae4ce@2ndquadrant.com
Amit Kapila [Sat, 27 Jun 2020 04:24:51 +0000 (09:54 +0530)]
Remove duplicate check added by commit
b2a5545bd6.
As this doesn't cause any harm so we decided to this clean up in HEAD only.
Author: Ádám Balogh
Discussion: https://postgr.es/m/VI1PR0702MB36631BD67559461AFDE1FEEE81920@VI1PR0702MB3663.eurprd07.prod.outlook.com
Alvaro Herrera [Sat, 27 Jun 2020 00:41:29 +0000 (20:41 -0400)]
Persist slot invalidation correctly
We failed to save slot to disk after invalidating it, so the state was
lost in case of server restart or crash. Fix by marking it dirty and
flushing.
Also, if the slot is known invalidated we don't need to reason about the
LSN at all -- it's known invalidated. Only test the LSN if the slot is
known not invalidated.
Author: Fujii Masao <masao.fujii@oss.nttdata.com>
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/
17a69cfe-f1c1-a416-ee25-
ae15427c69eb@oss.nttdata.com
Tom Lane [Fri, 26 Jun 2020 17:54:01 +0000 (13:54 -0400)]
Doc: explain that "timestamp - timestamp" applies justify_hours().
Back-patch to v13; before that, there's not really space for this
kind of detail.
Discussion: https://postgr.es/m/
c1696f68-fa8d-7759-6a9c-
eb293ab1bbc9@gmx.net
Bruce Momjian [Thu, 25 Jun 2020 22:33:28 +0000 (18:33 -0400)]
doc: mention trigger helper functions in CREATE TRIGGER docs
Reported-by: petermpallesen@gmail.com
Discussion: https://postgr.es/m/
159195294959.673.
5752624528747900508@wrigleys.postgresql.org
Backpatch-through: 9.5
Bruce Momjian [Thu, 25 Jun 2020 22:22:44 +0000 (18:22 -0400)]
docs: clarify that CREATE DATABASE does not copy db permissions
That is, those database permissions set by GRANT.
Diagnosed-by: Joseph Nahmias
Discussion: https://postgr.es/m/
20200614072613.GA21852@nahmias.net
Backpatch-through: 9.5
Peter Geoghegan [Thu, 25 Jun 2020 17:55:28 +0000 (10:55 -0700)]
Fix misuse of table_index_fetch_tuple_check().
Commit
0d861bbb, which added deduplication to nbtree, had
_bt_check_unique() pass a TID to table_index_fetch_tuple_check() that
isn't safe to mutate. table_index_fetch_tuple_check()'s tid argument is
modified when the TID in question is not the latest visible tuple in a
hot chain, though this wasn't documented.
To fix, go back to using a local copy of the TID in _bt_check_unique(),
and update comments above table_index_fetch_tuple_check().
Backpatch: 13-, where B-Tree deduplication was introduced.
Tom Lane [Thu, 25 Jun 2020 17:28:30 +0000 (13:28 -0400)]
Doc: correct nitpicky mistakes in array_position/array_positions examples.
Daniel Gustafsson and Erik Rijkers, per report from nick@cleaton
Discussion: https://postgr.es/m/
159275646273.679.
16940709892308114570@wrigleys.postgresql.org
Fujii Masao [Thu, 25 Jun 2020 02:13:13 +0000 (11:13 +0900)]
Remove erroneous assertion from pg_copy_logical_replication_slot().
If restart_lsn of logical replication slot gets behind more than
max_slot_wal_keep_size from the current LSN, the logical replication slot
would be invalidated and its restart_lsn is reset to an invalid LSN.
If this logical replication slot with an invalid restart_lsn was specified as
the source slot in pg_copy_logical_replication_slot(), the function caused
the assertion failure unexpectedly.
This assertion was added because restart_lsn should not be invalid before.
But in v13, it can be invalid thanks to max_slot_wal_keep_size. So since this
assertion is no longer useful, this commit removes it.
This commit also changes the errcode in the error message that
pg_copy_logical_replication_slot() emits when the slot with an invalid
restart_lsn is specified, to more appropriate one.
Back-patch to v13 where max_slot_wal_keep_size was added and
the assertion was no longer valid.
Author: Fujii Masao
Reviewed-by: Alvaro Herrera, Kyotaro Horiguchi
Discussion: https://postgr.es/m/
f91de4fb-a7ab-b90e-8132-
74796e049d51@oss.nttdata.com
Tom Lane [Wed, 24 Jun 2020 19:47:30 +0000 (15:47 -0400)]
Fix compiler warning induced by commit
d8b15eeb8.
I forgot that INT64_FORMAT can't be used with sscanf on Windows.
Use the same trick of sscanf'ing into a temp variable as we do in
some other places in zic.c.
The upstream IANA code avoids the portability problem by relying on
<inttypes.h>'s SCNdFAST64 macro. Once we're requiring C99 in all
branches, we should do likewise and drop this set of diffs from
upstream. For now, though, a hack seems fine, since we do not
actually care about leapseconds anyway.
Discussion: https://postgr.es/m/
4e5d1a5b-143e-e70e-a99d-
a3b01c1ae7c3@2ndquadrant.com
Alvaro Herrera [Wed, 24 Jun 2020 18:23:39 +0000 (14:23 -0400)]
Adjust max_slot_wal_keep_size behavior per review
In pg_replication_slot, change output from normal/reserved/lost to
reserved/extended/unreserved/ lost, which better expresses the possible
states particularly near the time where segments are no longer safe but
checkpoint has not run yet.
Under the new definition, reserved means the slot is consuming WAL
that's still under the normal WAL size constraints; extended means it's
consuming WAL that's being protected by wal_keep_segments or the slot
itself, whose size is below max_slot_wal_keep_size; unreserved means the
WAL is no longer safe, but checkpoint has not yet removed those files.
Such as slot is in imminent danger, but can still continue for a little
while and may catch up to the reserved WAL space.
Also, there were some bugs in the calculations used to report the
status; fixed those.
Backpatch to 13.
Reported-by: Fujii Masao <masao.fujii@oss.nttdata.com>
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reviewed-by: Fujii Masao <masao.fujii@oss.nttdata.com>
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/
20200616.120236.
1809496990963386593.horikyota.ntt@gmail.com
Alvaro Herrera [Wed, 24 Jun 2020 18:15:17 +0000 (14:15 -0400)]
Save slot's restart_lsn when invalidated due to size
We put it aside as invalidated_at, which let us show "lost" in
pg_replication slot. Prior to this change, the state value was reported
as NULL.
Backpatch to 13.
Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/
20200617.101707.
1735599255100002667.horikyota.ntt@gmail.com
Discussion: https://postgr.es/m/
20200407.120905.
1507671100168805403.horikyota.ntt@gmail.com
Alvaro Herrera [Wed, 24 Jun 2020 18:00:37 +0000 (14:00 -0400)]
Add parens to ConvertToXSegs macro
The current definition is dangerous. No bugs exist in our code at
present, but backpatch to 11 nonetheless where it was introduced.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Michael Paquier [Wed, 24 Jun 2020 06:14:04 +0000 (15:14 +0900)]
Fix comment in heap.c
The description of InsertPgAttributeTuple() does not match its handling
of pg_attribute contents with NULL values for a long time, with
911e702
making things more inconsistent. This adjusts the description to match
the reality.
Author: Daniel Gustafsson
Discussion: https://postgr.es/m/
4E4E4B33-9FDF-4D21-B77A-
642D027AEAD9@yesql.se
Jeff Davis [Mon, 22 Jun 2020 19:14:55 +0000 (12:14 -0700)]
Doc fixup for hashagg_avoid_disk_plan GUC.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/
20200620220402.GZ17995@telsasoft.com
Backport-through: 13
Tom Lane [Mon, 22 Jun 2020 15:46:41 +0000 (11:46 -0400)]
Undo double-quoting of index names in non-text EXPLAIN output formats.
explain_get_index_name() applied quote_identifier() to the index name.
This is fine for text output, but the non-text output formats all have
their own quoting conventions and would much rather start from the
actual index name. For example in JSON you'd get something like
"Index Name": "\"My Index\"",
which is surely not desirable, especially when the same does not
happen for table names. Hence, move the responsibility for applying
quoting out to the callers, where it can go into already-existing
special code paths for text format.
This changes the API spec for users of explain_get_index_name_hook:
before, they were supposed to apply quote_identifier() if necessary,
now they should not. Research suggests that the only publicly
available user of the hook is hypopg, and it actually forgot to
apply quoting anyway, so it's fine. (In any case, there's no
behavioral change for the output of a hook as seen in non-text
EXPLAIN formats, so this won't break any case that programs should
be relying on.)
Digging in the commit logs, it appears that quoting was included in
explain_get_index_name's duties when commit
604ffd280 invented it;
and that was fine at the time because we only had text output format.
This should have been rethought when non-text formats were invented,
but it wasn't.
This is a fairly clear bug for users of non-text EXPLAIN formats,
so back-patch to all supported branches.
Per bug #16502 from Maciek Sakrejda. Patch by me (based on
investigation by Euler Taveira); thanks to Julien Rouhaud for review.
Discussion: https://postgr.es/m/16502-
57bd1c9f913ed1d1@postgresql.org
Michael Paquier [Mon, 22 Jun 2020 04:40:04 +0000 (13:40 +0900)]
Fix inconsistent markups in catalogs.sgml
Some fields related to pg_opclass and pg_opfamily were using incorrect
markups, listing them as structname instead of structfield.
Author: Fabien Coelho
Discussion: https://postgr.es/m/alpine.DEB.2.22.394.
2006210903560.859381@pseudo
Michael Paquier [Mon, 22 Jun 2020 04:23:38 +0000 (13:23 +0900)]
Add --no-index-cleanup and --no-truncate to vacuumdb.
Both INDEX_CLEANUP and TRUNCATE have been available since v12, and are
enabled by default except if respectively vacuum_index_cleanup and
vacuum_truncate are disabled for a given relation. This change adds
support for disabling these options from vacuumdb.
Author: Nathan Bossart
Reviewed-by: Michael Paquier, Masahiko Sawada
Discussion: https://postgr.es/m/
6F7F17EF-B1F2-4681-8D03-
BA96365717C0@amazon.com
Alexander Korotkov [Sun, 21 Jun 2020 01:48:03 +0000 (04:48 +0300)]
Language fixes for docs related to opclass options
Discussion: https://postgr.es/m/
20200620232145.GB17995%40telsasoft.com
Author: Justin Pryzby
Backpatch-through: 13
Peter Geoghegan [Sun, 21 Jun 2020 00:34:07 +0000 (17:34 -0700)]
Doc: Tweak description of B-Tree duplicate tuples.
Defining duplicates as "close by" to each other was unclear. Simplify
the definition.
Backpatch: 13-, where deduplication was introduced (by commit
0d861bbb)
Alexander Korotkov [Sat, 20 Jun 2020 21:35:42 +0000 (00:35 +0300)]
Minor corrections to docs related to opclass options
Reported-by: Peter Geoghegan
Discussion: https://postgr.es/m/CAH2-WzmwhYbxuoL0WjTLaiCxW3gj6qadeNpBhWAo_KZsE5-FGw%40mail.gmail.com
Alexander Korotkov [Sat, 20 Jun 2020 14:34:51 +0000 (17:34 +0300)]
Fix masking of SP-GiST pages during xlog consistency check
spg_mask() didn't take into account that pd_lower equal to SizeOfPageHeaderData
is still valid value. This commit fixes that. Backpatch to 11, where
spg_mask() pg_lower check was introduced.
Reported-by: Michael Paquier
Discussion: https://postgr.es/m/
20200615131405.GM52676%40paquier.xyz
Backpatch-through: 11
Alexander Korotkov [Sat, 20 Jun 2020 10:34:54 +0000 (13:34 +0300)]
Add documentation for opclass options
911e7020770 added opclass options and adjusted documentation for each
particular affected opclass. However, documentation for extendability was
not adjusted. This commit adjusts documentation for interfaces of index AMs
and opclasses.
Discussion: https://postgr.es/m/CAH2-WzmQnW6%2Bz5F9AW%2BSz%2BzEcEvXofTwh_A9J3%3D_WA-FBP0wYg%40mail.gmail.com
Author: Alexander Korotkov
Reported-by: Peter Geoghegan
Reviewed-by: Peter Geoghegan
Noah Misch [Sat, 20 Jun 2020 08:25:40 +0000 (01:25 -0700)]
Remove dead forceSync parameter of XactLogCommitRecord().
The function has been reading global variable forceSyncCommit, mirroring
the intent of the caller that passed forceSync=forceSyncCommit. The
other caller, RecordTransactionCommitPrepared(), passed false. Since
COMMIT PREPARED can't share a transaction with any command, it certainly
doesn't share a transaction with a command that sets forceSyncCommit.
Reviewed by Michael Paquier.
Discussion: https://postgr.es/m/
20200617032615.GC2916904@rfd.leadboat.com
Amit Kapila [Sat, 20 Jun 2020 03:48:57 +0000 (09:18 +0530)]
Removal unused function parameter in CopyReadBinaryAttribute.
The function parameter column_no is not used in CopyReadBinaryAttribute,
this can be removed.
Commit
0e319c7ad7 removed the usage of column_no parameter in function
CopyReadBinaryAttribute but forgot to remove the parameter.
Reported-by: Vignesh C
Author: Vignesh C
Discussion: https://postgr.es/m/CALDaNm1TYSNTfqx_jfz9_mwEZ2Er=dZnu++duXpC1uQo1cG=WA@mail.gmail.com
Alvaro Herrera [Fri, 19 Jun 2020 20:46:07 +0000 (16:46 -0400)]
Ensure write failure reports no-disk-space
A few places calling fwrite and gzwrite were not setting errno to ENOSPC
when reporting errors, as is customary; this led to some failures being
reported as
"could not write file: Success"
which makes us look silly. Make a few of these places in pg_dump and
pg_basebackup use our customary pattern.
Backpatch-to: 9.5
Author: Justin Pryzby <pryzby@telsasoft.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Discussion: https://postgr.es/m/
20200611153753.GU14879@telsasoft.com