Jeff Davis [Tue, 24 Mar 2020 01:55:12 +0000 (18:55 -0700)]
Reduce test time for disk-based Hash Aggregation.
Discussion: https://postgr.es/m/23196.
1584943506@sss.pgh.pa.us
Fujii Masao [Tue, 24 Mar 2020 01:43:41 +0000 (10:43 +0900)]
Report NULL as total backup size if it's not estimated.
Previously 0 was reported in pg_stat_progress_basebackup.total_backup
if the total backup size was not estimated. Per discussion, our consensus
is that NULL is better choise as the value in total_backup in that case.
So this commit makes pg_stat_progress_basebackup view report NULL
in total_backup column if the estimation is disabled.
Bump catversion.
Author: Fujii Masao
Reviewed-by: Amit Langote, Magnus Hagander, Alvaro Herrera
Discussion: https://postgr.es/m/CABUevExnhOD89zBDuPvfAAh243RzNpwCPEWNLtMYpKHMB8gbAQ@mail.gmail.com
Jeff Davis [Mon, 23 Mar 2020 20:56:28 +0000 (13:56 -0700)]
Fixes for Disk-based Hash Aggregation.
Justin Pryzby raised a couple issues with commit
1f39bce0. Fixed.
Also, tweak the way the size of a hash entry is estimated and the
number of buckets is estimated when calling BuildTupleHashTableExt().
Discussion: https://www.postgresql.org/message-id/
20200319064222.GR26184@telsasoft.com
Bruce Momjian [Mon, 23 Mar 2020 22:38:42 +0000 (18:38 -0400)]
docs: add backend_type to file-fdw CSV log example
backend_type was added to the CVS log output in commit
70a7b4776b.
Reported-by: Fabrízio de Royes Mello
Discussion: https://postgr.es/m/CAFcNs+ruvRks3BV1j7yQ-MvxsswmKJa0cVh2yK5Dd-xXVM8wPw@mail.gmail.com
Backpatch-through: master
Andres Freund [Mon, 23 Mar 2020 21:48:19 +0000 (14:48 -0700)]
Add regression tests for constraint errors in partitioned tables.
While #16293 only applied to 11 (and 10 to some degree), it seems best
to add tests to all branches with partitioning support.
Reported-By: Daniel WM
Author: Andres Freund
Bug: #16293
Discussion: https://postgr.es/m/16293-
26f5777d10143a66@postgresql.org
Backpatch: 10-
Alexander Korotkov [Mon, 23 Mar 2020 21:54:33 +0000 (00:54 +0300)]
Fix ordering in typedefs.list
Tom Lane [Mon, 23 Mar 2020 16:42:15 +0000 (12:42 -0400)]
Doc: explain that LIKE et al can be used in ANY (sub-select) etc.
This wasn't stated anywhere, and it's perhaps not that obvious,
since we get questions about it from time to time. Also undocumented
was that the parser actually translates these into operators.
Discussion: https://postgr.es/m/CAFj8pRBkvZ71BqGKZnBBG4=0cKG+s50Dy+DYmrizUKEpAtdc+w@mail.gmail.com
Tom Lane [Mon, 23 Mar 2020 15:58:00 +0000 (11:58 -0400)]
Fix our getopt_long's behavior for a command line argument of just "-".
src/port/getopt_long.c failed on such an argument, always seeing it
as an unrecognized switch. This is unhelpful; better is to treat such
an item as a non-switch argument. That behavior is what we find in
GNU's getopt_long(); it's what src/port/getopt.c does; and it is
required by POSIX for getopt(), which getopt_long() ought to be
generally a superset of. Moreover, it's expected by ecpg, which
intends an argument of "-" to mean "read from stdin". So fix it.
Also add some documentation about ecpg's behavior in this area, since
that was miserably underdocumented. I had to reverse-engineer it
from the code.
Per bug #16304 from James Gray. Back-patch to all supported branches,
since this has been broken forever.
Discussion: https://postgr.es/m/16304-
c662b00a1322db7f@postgresql.org
Michael Paquier [Mon, 23 Mar 2020 04:38:03 +0000 (13:38 +0900)]
Doc: Fix type of some storage parameters in CREATE TABLE page
autovacuum_vacuum_scale_factor and autovacuum_analyze_scale_factor have
been documented as "float4", but "floating type" is used in this case
for GUCs and relation options in the documentation.
Author: Atsushi Torikoshi
Discussion: https://postgr.es/m/CACZ0uYFf_p9BpbjLccx3CA=eM1Hk2Te=ULY4iptGLUhL-JxCPA@mail.gmail.com
Backpatch-through: 9.5
Michael Paquier [Mon, 23 Mar 2020 03:52:37 +0000 (12:52 +0900)]
Revert "Refactor compile-time assertion checks in c.h"
This reverts commit
b7f64c6, which broke the fallback implementation for
C++. We have discussed a couple of alternatives to reduce the number of
implementations for those asserts, but nothing allowing to reduce the
number of implementations down to three instead of four, so there is no
benefit in keeping this patch.
Thanks to Tom Lane for the discussion.
Discussion: https://postgr.es/m/
20200313115033.GA183471@paquier.xyz
Amit Kapila [Mon, 23 Mar 2020 02:39:15 +0000 (08:09 +0530)]
Add object names to partition integrity violations.
All errors of SQLSTATE class 23 should include the name of an object
associated with the error in separate fields of the error report message.
We do this so that applications need not try to extract them from the
possibly-localized human-readable text of the message.
Reported-by: Chris Bandy
Author: Chris Bandy
Reviewed-by: Amit Kapila and Amit Langote
Discussion: https://postgr.es/m/
0aa113a3-3c7f-db48-bcd8-
f9290b2269ae@gmail.com
Michael Paquier [Mon, 23 Mar 2020 02:01:41 +0000 (11:01 +0900)]
Add bound checks for ssl_min_protocol_version and ssl_max_protocol_version
Mixing incorrect bounds in the SSL context leads to confusing error
messages generated by OpenSSL which are hard to act on. New range
checks are added when both min/max parameters are loaded in the context
of a SSL reload to improve the error reporting. Note that this does not
make use of the GUC hook machinery contrary to
41aadee, as there is no
way to ensure a consistent range check (except if there is a way one day
to define range types for GUC parameters?). Hence, this patch applies
only to OpenSSL, and uses a logic similar to other parameters to trigger
an error when reloading the SSL context in a session.
Author: Michael Paquier
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/
20200114035420.GE1515@paquier.xyz
Noah Misch [Sun, 22 Mar 2020 16:24:09 +0000 (09:24 -0700)]
Revert "Skip WAL for new relfilenodes, under wal_level=minimal."
This reverts commit
cb2fd7eac285b1b0a24eeb2b8ed4456b66c5a09f. Per
numerous buildfarm members, it was incompatible with parallel query, and
a test case assumed LP64. Back-patch to 9.5 (all supported versions).
Discussion: https://postgr.es/m/
20200321224920.GB1763544@rfd.leadboat.com
Tom Lane [Sat, 21 Mar 2020 22:28:44 +0000 (18:28 -0400)]
Fix up recent breakage of headerscheck and cpluspluscheck.
headerscheck and cpluspluscheck should skip the recently-added
cmdtaglist.h header, since (like kwlist.h and some other similarly-
designed headers) it's not meant to be included standalone.
evtcache.h was missing an #include to support its usage of Bitmapset.
typecmds.h was missing an #include to support its usage of ParseState.
The first two of these were evidently oversights in commit
2f9661311.
I didn't track down exactly which change broke typecmds.h, but it
must have been some rearrangement in one of its existing inclusions,
because it's referenced ParseState for quite a long time and there
were not complaints from these checking programs before.
Noah Misch [Sat, 21 Mar 2020 16:38:26 +0000 (09:38 -0700)]
Skip WAL for new relfilenodes, under wal_level=minimal.
Until now, only selected bulk operations (e.g. COPY) did this. If a
given relfilenode received both a WAL-skipping COPY and a WAL-logged
operation (e.g. INSERT), recovery could lose tuples from the COPY. See
src/backend/access/transam/README section "Skipping WAL for New
RelFileNode" for the new coding rules. Maintainers of table access
methods should examine that section.
To maintain data durability, just before commit, we choose between an
fsync of the relfilenode and copying its contents to WAL. A new GUC,
wal_skip_threshold, guides that choice. If this change slows a workload
that creates small, permanent relfilenodes under wal_level=minimal, try
adjusting wal_skip_threshold. Users setting a timeout on COMMIT may
need to adjust that timeout, and log_min_duration_statement analysis
will reflect time consumption moving to COMMIT from commands like COPY.
Internally, this requires a reliable determination of whether
RollbackAndReleaseCurrentSubTransaction() would unlink a relation's
current relfilenode. Introduce rd_firstRelfilenodeSubid. Amend the
specification of rd_createSubid such that the field is zero when a new
rel has an old rd_node. Make relcache.c retain entries for certain
dropped relations until end of transaction.
Back-patch to 9.5 (all supported versions). This introduces a new WAL
record type, XLOG_GIST_ASSIGN_LSN, without bumping XLOG_PAGE_MAGIC. As
always, update standby systems before master systems. This changes
sizeof(RelationData) and sizeof(IndexStmt), breaking binary
compatibility for affected extensions. (The most recent commit to
affect the same class of extensions was
089e4d405d0f3b94c74a2c6a54357a84a681754b.)
Kyotaro Horiguchi, reviewed (in earlier, similar versions) by Robert
Haas. Heikki Linnakangas and Michael Paquier implemented earlier
designs that materially clarified the problem. Reviewed, in earlier
designs, by Andrew Dunstan, Andres Freund, Alvaro Herrera, Tom Lane,
Fujii Masao, and Simon Riggs. Reported by Martijn van Oosterhout.
Discussion: https://postgr.es/m/
20150702220524.GA9392@svana.org
Noah Misch [Sat, 21 Mar 2020 16:38:26 +0000 (09:38 -0700)]
In log_newpage_range(), heed forkNum and page_std arguments.
The function assumed forkNum=MAIN_FORKNUM and page_std=true, ignoring
the actual arguments. Existing callers passed exactly those values, so
there's no live bug. Back-patch to v12, where the function first
appeared, because another fix needs this.
Discussion: https://postgr.es/m/
20191118045434.GA1173436@rfd.leadboat.com
Noah Misch [Sat, 21 Mar 2020 16:38:26 +0000 (09:38 -0700)]
During heap rebuild, lock any TOAST index until end of transaction.
swap_relation_files() calls toast_get_valid_index() to find and lock
this index, just before swapping with the rebuilt TOAST index. The
latter function releases the lock before returning. Potential for
mischief is low; a concurrent session can issue ALTER INDEX ... SET
(fillfactor = ...), which is not alarming. Nonetheless, changing
pg_class.relfilenode without a lock is unconventional. Back-patch to
9.5 (all supported versions), because another fix needs this.
Discussion: https://postgr.es/m/
20191226001521.GA1772687@rfd.leadboat.com
Noah Misch [Sat, 21 Mar 2020 16:38:26 +0000 (09:38 -0700)]
Fix cosmetic blemishes involving rd_createSubid.
Remove an obsolete comment from AtEOXact_cleanup(). Restore formatting
of a comment in struct RelationData, mangled by the pgindent run in
commit
9af4159fce6654aa0e081b00d02bca40b978745c. Back-patch to 9.5 (all
supported versions), because another fix stacks on this.
Amit Kapila [Sat, 21 Mar 2020 03:18:06 +0000 (08:48 +0530)]
Allow page lock to conflict among parallel group members.
This is required as it is no safer for two related processes to perform
clean up in gin indexes at a time than for unrelated processes to do the
same. After acquiring page locks, we can acquire relation extension lock
but reverse never happens which means these will also not participate in
deadlock. So, avoid checking wait edges from this lock.
Currently, the parallel mode is strictly read-only, but after this patch
we have the infrastructure to allow parallel inserts and parallel copy.
Author: Dilip Kumar, Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Sawada Masahiko
Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com
Bruce Momjian [Sat, 21 Mar 2020 00:19:32 +0000 (20:19 -0400)]
docs: use alias in WHERE clause of full text search example
The current doc query specified an alias in the FROM clause and used in
it the target list, but not in the WHERE clause.
Reported-by: axykon@gmail.com
Discussion: https://postgr.es/m/
158316348159.30450.
16075357948244298217@wrigleys.postgresql.org
Backpatch-through: 9.5
Alvaro Herrera [Fri, 20 Mar 2020 21:11:28 +0000 (18:11 -0300)]
Fix bogus last-minute edit in
4e62091341b4
Noticed by Erik Rijkers before I was able to push the fix.
Alvaro Herrera [Fri, 20 Mar 2020 20:21:00 +0000 (17:21 -0300)]
pg_dump: Add FOREIGN to ALTER statements, if appropriate
Author: Luis Carril
Reviewed-by: Tomas Vondra, Daniel Gustafsson, Álvaro Herrera
Discussion: https://postgr.es/m/LEJPR01MB0185A19B2E7C98E5E2A031F5E7F20@LEJPR01MB0185.DEUPRD01.PROD.OUTLOOK.DE
Andrew Dunstan [Fri, 20 Mar 2020 17:55:15 +0000 (13:55 -0400)]
Turn off deprecated bison warnings under MSVC
These are disabled by the configure code, so this is just fixing an
inconsistency in the MSVC code.
Backpatch to all live branches.
Peter Eisentraut [Fri, 20 Mar 2020 15:04:15 +0000 (16:04 +0100)]
psql: Catch and report errors while printing result table
Errors (for example I/O errors or disk full) while printing out result
tables were completely ignored, which could result in silently
truncated output in scripts, for example. Fix by adding some basic
error checking and reporting.
Author: Daniel Verite <daniel@manitou-mail.org>
Author: David Zhang <david.zhang@highgo.ca>
Discussion: https://www.postgresql.org/message-id/flat/
9a0b3c8d-ee14-4b1d-9d0a-
2c993bdabacc@manitou-mail.org
Amit Kapila [Fri, 20 Mar 2020 02:50:56 +0000 (08:20 +0530)]
Allow relation extension lock to conflict among parallel group members.
This is required as it is no safer for two related processes to extend the
same relation at a time than for unrelated processes to do the same. We
don't acquire a heavyweight lock on any other object after relation
extension lock which means such a lock can never participate in the
deadlock cycle. So, avoid checking wait edges from this lock.
This provides an infrastructure to allow parallel operations like insert,
copy, etc. which were earlier not possible as parallel group members won't
conflict for relation extension lock.
Author: Dilip Kumar, Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Sawada Masahiko
Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com
Peter Geoghegan [Thu, 19 Mar 2020 21:56:56 +0000 (14:56 -0700)]
nbtree: Remove obsolete _bt_pgaddtup() comments.
Remove comments that are a throw back to a time when nbtree cared about
write-ordering dependencies. The comments are similar to those removed
by commit
9ee7414e, among others.
Jeff Davis [Thu, 19 Mar 2020 18:20:39 +0000 (11:20 -0700)]
Revert "Specialize MemoryContextMemAllocated()."
This reverts commit
e00912e11a9ec2d29274ed8a6465e81385906dc2.
Bruce Momjian [Thu, 19 Mar 2020 19:20:55 +0000 (15:20 -0400)]
pg_upgrade: make get_major_server_version() err msg consistent
This patch fixes the error message in get_major_server_version() to be
"could not parse version file", and uses the full file path name, rather
than just the data directory path.
Also, commit
4109bb5de4 added the cause of the failure to the "could
not open" error message, and improved quoting. This patch backpatches
the "could not open" cause to PG 12, where it was first widely used, and
backpatches the quoting fix in that patch to all supported releases.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/87pne2w98h.fsf@wibble.ilmari.org
Author: Dagfinn Ilmari Mannsåker
Backpatch-through: 9.5
Alexander Korotkov [Thu, 19 Mar 2020 18:40:45 +0000 (21:40 +0300)]
Add new typedefs introduced in
773df883e8 to typedefs.list
Tom Lane [Thu, 19 Mar 2020 15:43:11 +0000 (11:43 -0400)]
Introduce "anycompatible" family of polymorphic types.
This patch adds the pseudo-types anycompatible, anycompatiblearray,
anycompatiblenonarray, and anycompatiblerange. They work much like
anyelement, anyarray, anynonarray, and anyrange respectively, except
that the actual input values need not match precisely in type.
Instead, if we can find a common supertype (using the same rules
as for UNION/CASE type resolution), then the parser automatically
promotes the input values to that type. For example,
"myfunc(anycompatible, anycompatible)" can match a call with one
integer and one bigint argument, with the integer automatically
promoted to bigint. With anyelement in the definition, the user
would have had to cast the integer explicitly.
The new types also provide a second, independent set of type variables
for function matching; thus with "myfunc(anyelement, anyelement,
anycompatible) returns anycompatible" the first two arguments are
constrained to be the same type, but the third can be some other
type, and the result has the type of the third argument. The need
for more than one set of type variables was foreseen back when we
first invented the polymorphic types, but we never did anything
about it.
Pavel Stehule, revised a bit by me
Discussion: https://postgr.es/m/CAFj8pRDna7VqNi8gR+Tt2Ktmz0cq5G93guc3Sbn_NVPLdXAkqA@mail.gmail.com
Fujii Masao [Thu, 19 Mar 2020 08:09:00 +0000 (17:09 +0900)]
Make pg_basebackup ask the server to estimate the total backup size, by default.
This commit changes pg_basebackup so that it specifies PROGRESS option in
BASE_BACKUP replication command whether --progress is specified or not.
This causes the server to estimate the total backup size and report it in
pg_stat_progress_basebackup.backup_total, by default. This is reasonable
default because the time required for the estimation would not be so large
in most cases.
Also this commit adds new option --no-estimate-size to pg_basebackup.
This option prevents the server from the estimation, and so is useful to
avoid such estimation time if it's too long.
Author: Fujii Masao
Reviewed-by: Magnus Hagander, Amit Langote
Discussion: https://postgr.es/m/CABUevEyDPPSjP7KRvfTXPdqOdY5aWNkqsB5aAXs3bco5ZwtGHg@mail.gmail.com
Peter Eisentraut [Thu, 19 Mar 2020 07:17:50 +0000 (08:17 +0100)]
Prepare to support non-tables in publications
This by itself doesn't change any functionality but prepares the way
for having relations other than base tables in publications.
Make arrangements for COPY handling the initial table sync. For
non-tables we have to use COPY (SELECT ...) instead of directly
copying from the table, but then we have to take care to omit
generated columns from the column list.
Also, remove a hardcoded reference to relkind = 'r' and rely on the
publisher to send only what it can actually publish, which will be
correct even in future cross-version scenarios.
Reviewed-by: Amit Langote <amitlangote09@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqH=Y85vRK3mOdjEkqFK+E=ST=eQiHdpj43L=_eJMOOznQ@mail.gmail.com
Fujii Masao [Thu, 19 Mar 2020 06:32:55 +0000 (15:32 +0900)]
Rename the recovery-related wait events.
This commit renames RecoveryWalAll and RecoveryWalStream wait events to
RecoveryWalStream and RecoveryRetrieveRetryInterval, respectively,
in order to make the names and what they are more consistent. For example,
previously RecoveryWalAll was reported as a wait event while the recovery
was waiting for WAL from a stream, and which was confusing because the name
was very different from the situation where the wait actually could happen.
The names of macro variables for those wait events also are renamed
accordingly.
This commit also changes the category of RecoveryRetrieveRetryInterval to
Timeout from Activity because the wait event is reported while waiting based
on wal_retrieve_retry_interval.
Author: Fujii Masao
Reviewed-by: Kyotaro Horiguchi, Atsushi Torikoshi
Discussion: https://postgr.es/m/
124997ee-096a-5d09-d8da-
2c7a57d0816e@oss.nttdata.com
Amit Kapila [Thu, 19 Mar 2020 02:41:45 +0000 (08:11 +0530)]
Add assert to ensure that page locks don't participate in deadlock cycle.
Assert that we don't acquire any other heavyweight lock while holding the
page lock except for relation extension. However, these locks are never
taken in reverse order which implies that page locks will never
participate in the deadlock cycle.
Similar to relation extension, page locks are also held for a short
duration, so imposing such a restriction won't hurt.
Author: Dilip Kumar, with few changes by Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Sawada Masahiko
Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com
Peter Geoghegan [Thu, 19 Mar 2020 01:17:37 +0000 (18:17 -0700)]
nbtree: Use raw PageAddItem() for retail inserts.
Only internal page splits need to call _bt_pgaddtup() instead of
PageAddItem(), and only for data items, one of which will end up at the
first offset (or first offset after the high key offset) on the new
right page. This data item alone will need to be truncated in
_bt_pgaddtup().
Since there is no reason why retail inserts ever need to truncate the
incoming item, use a raw PageAddItem() call there instead. Even
_bt_split() uses raw PageAddItem() calls for left page and right page
high keys. Clearly the _bt_pgaddtup() shim function wasn't really
encapsulating anything. _bt_pgaddtup() should now be thought of as a
_bt_split() helper function.
Note that the assertions from commit
d1e241c2 verify that retail inserts
never insert an item at an internal page's negative infinity offset.
This invariant could only ever be violated as a result of a basic logic
error in nbtinsert.c.
Michael Paquier [Thu, 19 Mar 2020 00:51:33 +0000 (09:51 +0900)]
Fix comment related to concurrent index swapping in index.c
A comment about switching indisvalid of the new and old indexes swapped
in REINDEX CONCURRENTLY got this backwards.
Issue introduced by
5dc92b8, the original commit of REINDEX
CONCURRENTLY.
Author: Julien Rouhaud
Discussion: https://postgr.es/m/
20200318143340.GA46897@nol
Backpatch-through: 12
Jeff Davis [Wed, 18 Mar 2020 22:42:02 +0000 (15:42 -0700)]
Disk-based Hash Aggregation.
While performing hash aggregation, track memory usage when adding new
groups to a hash table. If the memory usage exceeds work_mem, enter
"spill mode".
In spill mode, new groups are not created in the hash table(s), but
existing groups continue to be advanced if input tuples match. Tuples
that would cause a new group to be created are instead spilled to a
logical tape to be processed later.
The tuples are spilled in a partitioned fashion. When all tuples from
the outer plan are processed (either by advancing the group or
spilling the tuple), finalize and emit the groups from the hash
table. Then, create new batches of work from the spilled partitions,
and select one of the saved batches and process it (possibly spilling
recursively).
Author: Jeff Davis
Reviewed-by: Tomas Vondra, Adam Lee, Justin Pryzby, Taylor Vesely, Melanie Plageman
Discussion: https://postgr.es/m/
507ac540ec7c20136364b5272acbcd4574aa76ef.camel@j-davis.com
Jeff Davis [Wed, 18 Mar 2020 22:39:14 +0000 (15:39 -0700)]
Specialize MemoryContextMemAllocated().
An AllocSet doubles the size of allocated blocks (up to maxBlockSize),
which means that the current block can represent half of the total
allocated space for the memory context. But the free space in the
current block may never have been touched, so don't count the
untouched memory as allocated for the purposes of
MemoryContextMemAllocated().
Discussion: https://postgr.es/m/
ec63d70b668818255486a83ffadc3aec492c1f57.camel@j-davis.com
Alvaro Herrera [Wed, 18 Mar 2020 21:58:05 +0000 (18:58 -0300)]
Enable BEFORE row-level triggers for partitioned tables
... with the limitation that the tuple must remain in the same
partition.
Reviewed-by: Ashutosh Bapat
Discussion: https://postgr.es/m/
20200227165158.GA2071@alvherre.pgsql
Peter Geoghegan [Wed, 18 Mar 2020 21:42:49 +0000 (14:42 -0700)]
Refactor nbtree fastpath optimization.
Commit
2b272734, which added the fastpath rightmost leaf page cache
insert optimization, added code to _bt_doinsert() to handle using and
invalidating the backend local block cache. It doesn't seem like a good
place to handle these low level details, though. _bt_doinsert() is
supposed to be a high level function -- it is the main entry point to
nbtinsert.c.
Restructure the code by placing handling of the rightmost block cache at
the start of a new _bt_search() shim function, _bt_search_insert(). The
new function is called from _bt_doinsert(), which uses it as a
_bt_search() variant that conveniently accepts its BTInsertState state
as an argument. _bt_doinsert() no longer needs to directly consider the
fastpath optimization.
Discussion: https://postgr.es/m/CAH2-Wzk59cxKJRd=rfbyub6-V4yWRjsOYRkUNHBLT1P1GdtCQQ@mail.gmail.com
Peter Eisentraut [Wed, 18 Mar 2020 20:20:01 +0000 (21:20 +0100)]
Implement type regcollation
This will be helpful for a following commit and it's also just
generally useful, like the other reg* types.
Author: Julien Rouhaud
Reviewed-by: Thomas Munro and Michael Paquier
Discussion: https://postgr.es/m/CAEepm%3D0uEQCpfq_%2BLYFBdArCe4Ot98t1aR4eYiYTe%3DyavQygiQ%40mail.gmail.com
Tomas Vondra [Wed, 18 Mar 2020 15:48:12 +0000 (16:48 +0100)]
Document pg_statistic_ext.stxstattarget
Commit
d06215d03b added a new attribute to pg_statistic_ext catalog, but
failed to add it to document it properly.
Reported-by: Noriyoshi Shinoda <noriyoshi.shinoda@hpe.com>
Tomas Vondra [Wed, 18 Mar 2020 15:41:45 +0000 (16:41 +0100)]
Recognize some OR clauses as compatible with functional dependencies
Since commit
8f321bd16c functional dependencies can handle IN clauses,
which however introduced a possible (and surprising) inconsistency,
because IN clauses may be expressed as an OR clause, which are still
considered incompatible. For example
a IN (1, 2, 3)
may be rewritten as
(a = 1 OR a = 2 OR a = 3)
The IN clause will work fine with functional dependencies, but the OR
clause will force the estimation to fall back to plain per-column
estimates, possibly introducing significant estimation errors.
This commit recognizes OR clauses equivalent to an IN clause (when all
arugments are compatible and reference the same attribute) as a special
case, compatible with functional dependencies. This allows applying
functional dependencies, just like for IN clauses.
This does not eliminate the difference in estimating the clause itself,
i.e. IN clause and OR clause still use different formulas. It would be
possible to change that (for these special OR clauses), but that's not
really about extended statistics - it was always like this. Moreover the
errors are usually much smaller compared to ignoring dependencies.
Author: Tomas Vondra
Reviewed-by: Dean Rasheed
Discussion: https://www.postgresql.org/message-id/flat/
13902317.Eha0YfKkKy%40pierred-pdoc
Fujii Masao [Wed, 18 Mar 2020 14:07:17 +0000 (23:07 +0900)]
Correct the descriptions of recovery-related wait events in docs.
This commit corrects the descriptions of RecoveryWalAll and RecoveryWalStream
wait events in the documentation.
Back-patch to v10 where those wait events were added.
Author: Fujii Masao
Reviewed-by: Kyotaro Horiguchi, Atsushi Torikoshi
Discussion: https://postgr.es/m/
124997ee-096a-5d09-d8da-
2c7a57d0816e@oss.nttdata.com
Peter Eisentraut [Wed, 18 Mar 2020 13:51:37 +0000 (14:51 +0100)]
doc: Update documentation about reg* types
Add missing index entries, add missing information on pg_upgrade man
page, order things alphabetical instead of (apparently) in the order
they were implemented, reduce repetitiveness a bit.
Tomas Vondra [Wed, 18 Mar 2020 12:38:49 +0000 (13:38 +0100)]
Fix wording of several extended stats comments
Reported-by: Thomas Munro
Discussion: https://www.postgresql.org/message-id/flat/
20200113230008.g67iyk4cs3xbnjju@development
Fujii Masao [Wed, 18 Mar 2020 09:28:22 +0000 (18:28 +0900)]
Update the description of type of check_option reloption in docs.
Commit
773df883e8f7 changed the type of check_option reloption
from string to enum. But it forgot to update the description of
the type in the documentation.
Author: Atsushi Torikoshi
Discussion: https://postgr.es/m/CACZ0uYFvHF4n6yxF390YZgr4Q0Z0c2w0ihu=DLb8ipNOnNcqzQ@mail.gmail.com
Amit Kapila [Wed, 18 Mar 2020 03:57:14 +0000 (09:27 +0530)]
Add missing errcode() in a few ereport calls.
This will allow to specifying SQLSTATE error code for the errors in the
missing places.
Reported-by: Sawada Masahiko
Author: Sawada Masahiko
Backpatch-through: 9.5
Discussion: https://postgr.es/m/CA+fd4k6N8EjNvZpM8nme+y+05mz-SM8Z_BgkixzkA34R+ej0Kw@mail.gmail.com
Michael Paquier [Wed, 18 Mar 2020 02:13:12 +0000 (11:13 +0900)]
Fix typo in indexcmds.c
Introduced by
61d7c7b.
Backpatch-through: 12
Amit Kapila [Wed, 18 Mar 2020 01:50:17 +0000 (07:20 +0530)]
Assert that we don't acquire a heavyweight lock on another object after
relation extension lock.
The only exception to the rule is that we can try to acquire the same
relation extension lock more than once. This is allowed as we are not
creating any new lock for this case. This restriction implies that the
relation extension lock won't ever participate in the deadlock cycle
because we can never wait for any other heavyweight lock after acquiring
this lock.
Such a restriction is okay for relation extension locks as unlike other
heavyweight locks these are not held till the transaction end. These are
taken for a short duration to extend a particular relation and then
released.
Author: Dilip Kumar, with few changes by Amit Kapila
Reviewed-by: Amit Kapila, Kuntal Ghosh and Sawada Masahiko
Discussion: https://postgr.es/m/CAD21AoCmT3cFQUN4aVvzy5chw7DuzXrJCbrjTU05B+Ss=Gn1LA@mail.gmail.com
Peter Geoghegan [Wed, 18 Mar 2020 01:39:26 +0000 (18:39 -0700)]
nbtree: Remove useless local variables.
Copying block and offset numbers to local variables in _bt_insertonpg()
made the code less readable. Remove the variables. There is already
code that conditionally calls BufferGetBlockNumber() in the same block,
so consistently do it that way instead.
Calling BufferGetBlockNumber() is very cheap, but we might as well avoid
it when it isn't truly necessary. It isn't truly necessary for
_bt_insertonpg() to call BufferGetBlockNumber() in almost all cases.
Spotted while working on a patch that refactors the fastpath rightmost
leaf page cache optimization, which was added by commit
2b272734.
Thomas Munro [Tue, 17 Mar 2020 23:48:13 +0000 (12:48 +1300)]
Don't use EV_CLEAR for kqueue events.
For the semantics to match the epoll implementation, we need a socket to
continue to appear readable/writable if you wait multiple times without
doing I/O in between (in Linux terminology: level-triggered rather than
edge-triggered). This distinction will be important for later commits.
Similar to commit
3b790d256f8 for Windows.
Reviewed-by: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Discussion: https://postgr.es/m/CA%2BhUKGJAC4Oqao%3DqforhNey20J8CiG2R%3DoBPqvfR0vOJrFysGw%40mail.gmail.com
Thomas Munro [Tue, 17 Mar 2020 23:43:05 +0000 (12:43 +1300)]
Fix kqueue support under debugger on macOS.
While running under a debugger, macOS's getppid() can return the
debugger's PID. That could cause a backend to exit because it falsely
believed that the postmaster had died, since commit
815c2f09.
Continue to use getppid() as a fast postmaster check after adding the
postmaster's PID to a kqueue, to close a PID-reuse race, but double
check that it actually exited by trying to read the pipe. The new check
isn't reached in the common case.
Reported-by: Alexander Korotkov <a.korotkov@postgrespro.ru>
Discussion: https://postgr.es/m/CA%2BhUKGKhAxJ8V8RVwCo6zJaeVrdOG1kFBHGZOOjf6DzW_omeMA%40mail.gmail.com
Tom Lane [Tue, 17 Mar 2020 23:36:41 +0000 (19:36 -0400)]
Refactor our checks for valid function and aggregate signatures.
pg_proc.c and pg_aggregate.c had near-duplicate copies of the logic
to decide whether a function or aggregate's signature is legal.
This seems like a bad thing even without the problem that the
upcoming "anycompatible" patch would roughly double the complexity
of that logic. Hence, refactor so that the rules are localized
in new subroutines supplied by parse_coerce.c. (One could quibble
about just where to add that code, but putting it beside
enforce_generic_type_consistency seems not totally unreasonable.)
The fact that the rules are about to change would mandate some
changes in the wording of the associated error messages in any case.
I ended up spelling things out in a fairly literal fashion in the
errdetail messages, eg "A result of type anyelement requires at
least one input of type anyelement, anyarray, anynonarray, anyenum,
or anyrange." Perhaps this is overkill, but once there's more than
one subgroup of polymorphic types, people might get confused by
more-abstract messages.
Discussion: https://postgr.es/m/24137.
1584139352@sss.pgh.pa.us
Peter Geoghegan [Tue, 17 Mar 2020 22:53:05 +0000 (15:53 -0700)]
Doc: Correct deduplicate_items varlistentry id.
Use a varlistentry id for the deduplicate_items storage parameter that
is derived from the name of the parameter itself.
This oversight happened because the storage parameter was renamed
relatively late during the development of the patch that became commit
0d861bbb.
Tom Lane [Tue, 17 Mar 2020 22:29:07 +0000 (18:29 -0400)]
Adjust handling of an ANYARRAY actual input for an ANYARRAY argument.
Ordinarily it's impossible for an actual input of a function to have
declared type ANYARRAY, since we'd resolve that to a concrete array
type before doing argument type resolution for the function. But an
exception arises for functions applied to certain columns of pg_statistic
or pg_stats, since we abuse the "anyarray" pseudotype by using it to
declare those columns. So parse_coerce.c has to deal with the case.
Previously we allowed an ANYARRAY actual input to match an ANYARRAY
polymorphic argument, but only if no other argument or result was
declared ANYELEMENT. When that logic was written, those were the only
two polymorphic types, and I fear nobody thought carefully about how it
ought to extend to the other ones that came along later. But actually
it was wrong even then, because if a function has two ANYARRAY
arguments, it should be able to expect that they have identical element
types, and we'd not be able to ensure that.
The correct generalization is that we can match an ANYARRAY actual input
to an ANYARRAY polymorphic argument only if no other argument or result
is of any polymorphic type, so that no promises are being made about
element type compatibility. check_generic_type_consistency can't test
that condition, but it seems better anyway to accept such matches there
and then throw an error if needed in enforce_generic_type_consistency.
That way we can produce a specific error message rather than an
unintuitive "function does not exist" complaint. (There's some risk
perhaps of getting new ambiguous-function complaints, but I think that
any set of functions for which that could happen would be ambiguous
against ordinary array columns as well.) While we're at it, we can
improve the message that's produced in cases that the code did already
object to, as shown in the regression test changes.
Also, remove a similar test that got cargo-culted in for ANYRANGE;
there are no catalog columns of type ANYRANGE, and I hope we never
create any, so that's not needed. (It was incomplete anyway.)
While here, update some comments and rearrange the code a bit in
preparation for upcoming additions of more polymorphic types.
In practical situations I believe this is just exchanging one error
message for another, hopefully better, one. So it doesn't seem
needful to back-patch, even though the mistake is ancient.
Discussion: https://postgr.es/m/21569.
1584314271@sss.pgh.pa.us
Alvaro Herrera [Tue, 17 Mar 2020 21:18:01 +0000 (18:18 -0300)]
Remove logical_read_local_xlog_page
It devolved into a content-less wrapper over read_local_xlog_page, with
nothing to add, plus it's easily confused with walsender's
logical_read_xlog_page. There doesn't seem to be any reason for it to
stay.
src/include/replication/logicalfuncs.h becomes empty, so remove it too.
The prototypes it initially had were absorbed by generated fmgrprotos.h.
Discussion: https://postgr.es/m/
20191115214102.GA15616@alvherre.pgsql
Alvaro Herrera [Tue, 17 Mar 2020 19:13:18 +0000 (16:13 -0300)]
Fix consistency issues with replication slot copy
Commit
9f06d79ef831's replication slot copying failed to
properly reserve the WAL that the slot is expecting to see
during DecodingContextFindStartpoint (to set the confirmed_flush
LSN), so concurrent activity could remove that WAL and cause the
copy process to error out. But it doesn't actually *need* that
WAL anyway: instead of running decode to find confirmed_flush, it
can be copied from the source slot. Fix this by rearranging things
to avoid DecodingContextFindStartpoint() (leaving the target slot's
confirmed_flush_lsn to invalid), and set that up afterwards by copying
from the target slot's value.
Also ensure the source slot's confirmed_flush_lsn is valid.
Reported-by: Arseny Sher
Author: Masahiko Sawada, Arseny Sher
Discussion: https://postgr.es/m/871rr3ohbo.fsf@ars-thinkpad
Tom Lane [Tue, 17 Mar 2020 19:05:16 +0000 (15:05 -0400)]
Doc: clarify behavior of "anyrange" pseudo-type.
I noticed that we completely failed to document the restriction
that an "anyrange" result type has to be inferred from an "anyrange"
input. The docs also were less clear than they could be about the
relationship between "anyrange" and "anyarray".
It's been like this all along, so back-patch.
Tom Lane [Tue, 17 Mar 2020 18:54:46 +0000 (14:54 -0400)]
Remove bogus assertion about polymorphic SQL function result.
It is possible to reach check_sql_fn_retval() with an unresolved
polymorphic rettype, resulting in an assertion failure as demonstrated
by one of the added test cases. However, the code following that
throws what seems an acceptable error message, so just remove the
Assert and adjust commentary.
While here, I thought it'd be a good idea to provide some parallel
tests of SQL-function and PL/pgSQL-function polymorphism behavior.
Some of these cases are perhaps duplicative of tests elsewhere,
but we hadn't any organized coverage of the topic AFAICS.
Although that assertion's been wrong all along, it won't have any
effect in production builds, so I'm not bothering to back-patch.
Discussion: https://postgr.es/m/21569.
1584314271@sss.pgh.pa.us
Tom Lane [Tue, 17 Mar 2020 16:09:26 +0000 (12:09 -0400)]
Use pkg-config, if available, to locate libxml2 during configure.
If pkg-config is installed and knows about libxml2, use its information
rather than asking xml2-config. Otherwise proceed as before. This
patch allows "configure --with-libxml" to succeed on platforms that
have pkg-config but not xml2-config, which is likely to soon become
a typical situation.
The old mechanism can be forced by setting XML2_CONFIG explicitly
(hence, build processes that were already doing so will certainly
not need adjustment). Also, it's now possible to set XML2_CFLAGS
and XML2_LIBS explicitly to override both programs.
There is a small risk of this breaking existing build processes,
if there are multiple libxml2 installations on the machine and
pkg-config disagrees with xml2-config about which to use. The
only case where that seems really likely is if a builder has tried
to select a non-default xml2-config by putting it early in his PATH
rather than setting XML2_CONFIG. Plan to warn against that in the
minor release notes.
Back-patch to v10; before that we had no pkg-config infrastructure,
and it doesn't seem worth adding it for this.
Hugh McMaster and Tom Lane; Peter Eisentraut also made an earlier
attempt at this, from which I lifted most of the docs changes.
Discussion: https://postgr.es/m/CAN9BcdvfUwc9Yx5015bLH2TOiQ-M+t_NADBSPhMF7dZ=pLa_iw@mail.gmail.com
Fujii Masao [Tue, 17 Mar 2020 07:06:59 +0000 (16:06 +0900)]
Add the type information for index storage parameters to the documentation.
Author: Atsushi Torikoshi
Discussion: https://postgr.es/m/CACZ0uYFQebs4WT5eu3dK4qm_2PurZuvB++8nDvSBG0ebRWmbdg@mail.gmail.com
Fujii Masao [Tue, 17 Mar 2020 03:06:22 +0000 (12:06 +0900)]
Fix comment in xlog.c.
This commit fixes the comment about SharedHotStandbyActive variable.
The comment was apparently copy-and-pasted.
Author: Atsushi Torikoshi
Discussion: https://postgr.es/m/CACZ0uYEjpqZB9wN2Rwc_RMvDybyYqdbkPuDr1NyxJg4f9yGfMw@mail.gmail.com
Tom Lane [Tue, 17 Mar 2020 01:36:53 +0000 (21:36 -0400)]
Remove useless pfree()s at the ends of various ValuePerCall SRFs.
We don't need to manually clean up allocations in a SRF's
multi_call_memory_ctx, because the SRF_RETURN_DONE infrastructure
takes care of that (and also ensures that it will happen even if the
function never gets a final call, which simple manual cleanup cannot
do).
Hence, the code removed by this patch is a waste of code and cycles.
Worse, it gives the impression that cleaning up manually is a thing,
which can lead to more serious errors such as those fixed in
commits
085b6b667 and
b4570d33a. So we should get rid of it.
These are not quite actual bugs though, so I couldn't muster the
enthusiasm to back-patch. Fix in HEAD only.
Justin Pryzby
Discussion: https://postgr.es/m/
20200308173103.GC1357@telsasoft.com
Tom Lane [Tue, 17 Mar 2020 01:05:28 +0000 (21:05 -0400)]
Avoid holding a directory FD open across assorted SRF calls.
This extends the fixes made in commit
085b6b667 to other SRFs with the
same bug, namely pg_logdir_ls(), pgrowlocks(), pg_timezone_names(),
pg_ls_dir(), and pg_tablespace_databases().
Also adjust various comments and documentation to warn against
expecting to clean up resources during a ValuePerCall SRF's final
call.
Back-patch to all supported branches, since these functions were
all born broken.
Justin Pryzby, with cosmetic tweaks by me
Discussion: https://postgr.es/m/
20200308173103.GC1357@telsasoft.com
Peter Geoghegan [Mon, 16 Mar 2020 22:51:06 +0000 (15:51 -0700)]
nbtree: Fix obsolete _bt_search() comment.
Oversight in commit
d2086b08b02.
Alvaro Herrera [Mon, 16 Mar 2020 22:12:14 +0000 (19:12 -0300)]
Document pg_ls_*dir hiding of directories and special files
It's strange that a directory-listing function does not list all entries
in a directory, so let's at least document it. This involves
pg_ls_logdir
pg_ls_waldir
pg_ls_archive_statusdir
pg_ls_tmpdir
Backpatch as far back as it applies cleanly (and as far as as each
function exists). REL_10_STABLE uses different wording, but hopefully
people are not reading docs so old to write new apps anyway.
Author: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://postgr.es/m/
20200305161838.GJ684@telsasoft.com
Alvaro Herrera [Mon, 16 Mar 2020 21:38:28 +0000 (18:38 -0300)]
Update comment
I forgot to update it per last-minute edits leading to commit
2f9661311b83. Reported by Mark Dilger.
Discussion: https://postgr.es/m/
DA9A5554-AADD-4F33-96F9-
A1066EC9CAB5@enterprisedb.com>
Alvaro Herrera [Mon, 16 Mar 2020 19:27:13 +0000 (16:27 -0300)]
Plug memory leak
Introduced by
b08dee24a557. Noted by Coverity.
Peter Geoghegan [Mon, 16 Mar 2020 19:00:10 +0000 (12:00 -0700)]
nbtree: Pass down MAXALIGN()'d itemsz for new item.
Refactor nbtinsert.c so that the final itemsz of each new non-pivot
tuple (the MAXALIGN()'d size) is determined once. Most of the functions
used by leaf page inserts used the insertstate.itemsz value already.
This commit makes everything use insertstate.itemsz as standard
practice. The goal is to decouple tuple size from "effective" tuple
size. Making this distinction isn't truly necessary right now, but that
might change in the future.
Also explain why we consistently apply MAXALIGN() to get an effective
index tuple size. This was rather unclear, in part because it isn't
actually strictly necessary right now.
Thomas Munro [Sun, 15 Mar 2020 23:31:34 +0000 (12:31 +1300)]
Introduce a maintenance_io_concurrency setting.
Introduce a GUC and a tablespace option to control I/O prefetching, much
like effective_io_concurrency, but for work that is done on behalf of
many client sessions.
Use the new setting in heapam.c instead of the hard-coded formula
effective_io_concurrency + 10 introduced by commit
558a9165e08. Go with
a default value of 10 for now, because it's a round number pretty close
to the value used for that existing case.
Discussion: https://postgr.es/m/CA%2BhUKGJUw08dPs_3EUcdO6M90GnjofPYrWp4YSLaBkgYwS-AqA%40mail.gmail.com
Thomas Munro [Sun, 15 Mar 2020 22:43:18 +0000 (11:43 +1300)]
Simplify the effective_io_concurrency setting.
The effective_io_concurrency GUC and equivalent tablespace option were
previously passed through a formula based on a theory about RAID
spindles and probabilities, to arrive at the number of pages to prefetch
in bitmap heap scans. Tomas Vondra, Andres Freund and others argued
that it was anachronistic and hard to justify, and commit
558a9165e08
already started down the path of bypassing it in new code. We agreed to
drop that logic and use the value directly.
For the default setting of 1, there is no change in effect. Higher
settings can be converted from the old meaning to the new with:
select round(sum(OLD / n::float)) from generate_series(1, OLD) s(n);
We might want to consider renaming the GUC before the next release given
the change in meaning, but it's not clear that many users had set it
very carefully anyway. That decision is deferred for now.
Discussion: https://postgr.es/m/CA%2BhUKGJUw08dPs_3EUcdO6M90GnjofPYrWp4YSLaBkgYwS-AqA%40mail.gmail.com
Peter Geoghegan [Mon, 16 Mar 2020 03:53:12 +0000 (20:53 -0700)]
nbtree: Reorder nbtinsert.c prototypes.
Relocate _bt_newroot() prototype, so that the order that prototypes
appear in matches the order that the functions are defined in.
Peter Eisentraut [Sun, 15 Mar 2020 10:20:21 +0000 (11:20 +0100)]
Add backend type to csvlog and optionally log_line_prefix
The backend type, which corresponds to what
pg_stat_activity.backend_type shows, is added as a column to the
csvlog and can optionally be added to log_line_prefix using the new %b
placeholder.
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>
Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>
Reviewed-by: Justin Pryzby <pryzby@telsasoft.com>
Discussion: https://www.postgresql.org/message-id/flat/
c65e5196-4f04-4ead-9353-
6088c19615a3@2ndquadrant.com
Tomas Vondra [Sat, 14 Mar 2020 22:04:56 +0000 (23:04 +0100)]
Improve test coverage for multi-column MCV lists
The regression tests for extended statistics were not testing a couple
of important cases for the MCV lists:
* IS NOT NULL clauses - We did have queries with IS NULL clauses, but
not the negative case.
* clauses with variable on the right - All the clauses had the Var on
the left, i.e. (Var op Const), so this adds (Const op Var) too.
* columns with fixed-length types passed by reference - All columns
were using either by-value or varlena types, so add a test with
UUID columns too. This matters for (de)serialization.
* NULL-only dimension - When one of the columns contains only NULL
values, we treat it a a special case during (de)serialization.
* arrays containing NULL - When the constant parameter contains NULL
value, we need to handle it correctly during estimation, for all
IN, ANY and ALL clauses.
Discussion: https://www.postgresql.org/message-id/flat/
20200113230008.g67iyk4cs3xbnjju@development
Author: Tomas Vondra
Tomas Vondra [Sat, 14 Mar 2020 22:02:55 +0000 (23:02 +0100)]
Improve test coverage for functional dependencies
The regression tests for functional dependencies were only using clauses
of the form (Var op Const), i.e. with Var on the left side. This adds
a couple of queries with Var on the right, to test other code paths.
It also prints one of the functional dependencies, to test the data type
output function. The functional dependencies are "perfect" with degree
of 1.0 so this should be stable.
Discussion: https://www.postgresql.org/message-id/flat/
20200113230008.g67iyk4cs3xbnjju@development
Author: Tomas Vondra
Tom Lane [Sat, 14 Mar 2020 19:31:44 +0000 (15:31 -0400)]
Rearrange pseudotypes.c to get rid of duplicative code.
Commit
a5954de10 replaced a lot of manually-coded stub I/O routines
with code generated by macros. That was a good idea but it didn't
go far enough, because there were still manually-coded stub input
routines for types that had live output routines. Refactor the
macro so that we can generate just a stub input routine at need.
Also create similar macros to generate stub binary I/O routines,
since we have some of those now. The only stub functions that remain
hand-coded are shell_in() and shell_out(), which need to be separate
because they use different error messages.
While here, rearrange the commentary to discuss each type not each
function. This provides a better way to explain the *why* of which
types need which support, rather than just duplicatively annotating
the functions.
Discussion: https://postgr.es/m/24137.
1584139352@sss.pgh.pa.us
Tom Lane [Sat, 14 Mar 2020 18:42:22 +0000 (14:42 -0400)]
Restructure polymorphic-type resolution in funcapi.c.
resolve_polymorphic_tupdesc() and resolve_polymorphic_argtypes() failed to
cover the case of having to resolve anyarray given only an anyrange input.
The bug was masked if anyelement was also used (as either input or
output), which probably helps account for our not having noticed.
While looking at this I noticed that resolve_generic_type() would produce
the wrong answer if asked to make that same resolution. ISTM that
resolve_generic_type() is confusingly defined and overly complex, so
rather than fix it, let's just make funcapi.c do the specific lookups
it requires for itself.
With this change, resolve_generic_type() is not used anywhere, so remove
it in HEAD. In the back branches, leave it alone (complete with bug)
just in case any external code is using it.
While we're here, make some other refactoring adjustments in funcapi.c
with an eye to upcoming future expansion of the set of polymorphic types:
* Simplify quick-exit tests by adding an overall have_polymorphic_result
flag. This is about a wash now but will be a win when there are more
flags.
* Reduce duplication of code between resolve_polymorphic_tupdesc() and
resolve_polymorphic_argtypes().
* Don't bother to validate correct matching of anynonarray or anyenum;
the parser should have done that, and even if it didn't, just doing
"return false" here would lead to a very confusing, off-point error
message. (Really, "return false" in these two functions should only
occur if the call_expr isn't supplied or we can't obtain data type
info from it.)
* For the same reason, throw an elog rather than "return false" if
we fail to resolve a polymorphic type.
The bug's been there since we added anyrange, so back-patch to
all supported branches.
Discussion: https://postgr.es/m/6093.
1584202130@sss.pgh.pa.us
Tomas Vondra [Sat, 14 Mar 2020 13:56:37 +0000 (14:56 +0100)]
Use multi-variate MCV lists to estimate ScalarArrayOpExpr
Commit
8f321bd16c added support for estimating ScalarArrayOpExpr clauses
(IN/ANY) clauses using functional dependencies. There's no good reason
not to support estimation of these clauses using multi-variate MCV lists
too, so this commits implements that. That makes the behavior consistent
and MCV lists can estimate all variants (ANY/ALL, inequalities, ...).
Author: Tomas Vondra
Review: Dean Rasheed
Discussion: https://www.postgresql.org/message-id/flat/
13902317.Eha0YfKkKy%40pierred-pdoc
Tomas Vondra [Sat, 14 Mar 2020 13:55:59 +0000 (14:55 +0100)]
Use functional dependencies to estimate ScalarArrayOpExpr
Until now functional dependencies supported only simple equality clauses
and clauses that can be trivially translated to equalities. This commit
allows estimation of some ScalarArrayOpExpr (IN/ANY) clauses.
For IN clauses we can do this thanks to using operator with equality
semantics, which means an IN clause
WHERE c IN (1, 2, ..., N)
can be translated to
WHERE (c = 1 OR c = 2 OR ... OR c = N)
IN clauses are now considered compatible with functional dependencies,
and rely on the same assumption of consistency of queries with data
(which is an assumption we already used for simple equality clauses).
This applies also to ALL clauses with an equality operator, which can be
considered equivalent to IN clause.
ALL clauses are still considered incompatible, although there's some
discussion about maybe relaxing this in the future.
Author: Pierre Ducroquet
Reviewed-by: Tomas Vondra, Dean Rasheed
Discussion: https://www.postgresql.org/message-id/flat/
13902317.Eha0YfKkKy%40pierred-pdoc
Tom Lane [Fri, 13 Mar 2020 16:49:10 +0000 (12:49 -0400)]
Doc: fix mistaken reference to "PG_ARGNULL_xxx()" macro.
This should of course be just "PG_ARGISNULL()".
Also reorder a couple of paras to make the discussion of PG_ARGISNULL
less disjointed.
Back-patch to v10 where the error was introduced.
Laurenz Albe and Tom Lane, per an anonymous docs comment
Discussion: https://postgr.es/m/
158399487096.5708.
10696365251766477013@wrigleys.postgresql.org
Peter Eisentraut [Fri, 13 Mar 2020 14:45:37 +0000 (15:45 +0100)]
doc: Remove unused title ids
FOP issues warnings about them. These aren't even used, so just
remove them. For the ones that are actually used, we'll come up with
a different solution.
Discussion: https://www.postgresql.org/message-id/flat/
e29b580e-79ab-a371-5ea4-
6946e4d3af0b%402ndQuadrant.com
Peter Eisentraut [Wed, 11 Mar 2020 15:36:40 +0000 (16:36 +0100)]
Remove am_syslogger global variable
Use the new MyBackendType instead. More similar changes for other "am
something" variables are possible. This one was just particularly
simple.
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>
Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/
c65e5196-4f04-4ead-9353-
6088c19615a3@2ndquadrant.com
Peter Eisentraut [Wed, 11 Mar 2020 15:36:40 +0000 (16:36 +0100)]
Unify several ways to tracking backend type
Add a new global variable MyBackendType that uses the same BackendType
enum that was previously only used by the stats collector. That way
several duplicate ways of checking what type a particular process is
can be simplified. Since it's no longer just for stats, move to
miscinit.c and rename existing functions to match the expanded
purpose.
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>
Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/
c65e5196-4f04-4ead-9353-
6088c19615a3@2ndquadrant.com
Peter Eisentraut [Fri, 13 Mar 2020 10:28:11 +0000 (11:28 +0100)]
Preserve replica identity index across ALTER TABLE rewrite
If an index was explicitly set as replica identity index, this setting
was lost when a table was rewritten by ALTER TABLE. Because this
setting is part of pg_index but actually controlled by ALTER
TABLE (not part of CREATE INDEX, say), we have to do some extra work
to restore it.
Based-on-patch-by: Quan Zongliang <quanzongliang@gmail.com>
Reviewed-by: Euler Taveira <euler.taveira@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/
c70fcab2-4866-0d9f-1d01-
e75e189db342@gmail.com
Michael Paquier [Fri, 13 Mar 2020 06:04:11 +0000 (15:04 +0900)]
Refactor compile-time assertion checks in c.h
This commit refactors and simplifies the definitions of StaticAssertStmt,
StaticAssertExpr and StaticAssertDecl. By unifying the C and C++
fallback implementations, this reduces the number of different
implementations from four to three.
Author: Michael Paquier
Reviewed-by: Georgios Kokolatos, Tom Lane
Discussion: https://postgr.es/m/
20200204081503.GF2287@paquier.xyz
Tom Lane [Wed, 11 Mar 2020 22:23:57 +0000 (18:23 -0400)]
Fix test case instability introduced in
085b6b667.
I forgot that the WAL directory might hold other files besides WAL
segments, notably including new segments still being filled.
That means a blind test for the first file's size being 16MB can
fail. Restrict based on file name length to make it more robust.
Per buildfarm.
Alvaro Herrera [Wed, 11 Mar 2020 19:54:54 +0000 (16:54 -0300)]
Add pg_dump support for ALTER obj DEPENDS ON EXTENSION
pg_dump is oblivious to this kind of dependency, so they're lost on
dump/restores (and pg_upgrade). Have pg_dump emit ALTER lines so that
they're preserved. Add some pg_dump tests for the whole thing, also.
Reviewed-by: Tom Lane (offlist)
Reviewed-by: Ibrar Ahmed
Reviewed-by: Ahsan Hadi (who also reviewed commit 899a04f5ed61)
Discussion: https://postgr.es/m/
20200217225333.GA30974@alvherre.pgsql
Tom Lane [Wed, 11 Mar 2020 19:27:59 +0000 (15:27 -0400)]
Avoid holding a directory FD open across pg_ls_dir_files() calls.
This coding technique is undesirable because (a) it leaks the FD for
the rest of the transaction if the SRF is not run to completion, and
(b) allocated FDs are a scarce resource, but multiple interleaved
uses of the relevant functions could eat many such FDs.
In v11 and later, a query such as "SELECT pg_ls_waldir() LIMIT 1"
yields a warning about the leaked FD, and the only reason there's
no warning in earlier branches is that fd.c didn't whine about such
leaks before commit
9cb7db3f0. Even disregarding the warning, it
wouldn't be too hard to run a backend out of FDs with careless use
of these SQL functions.
Hence, rewrite the function so that it reads the directory within
a single call, returning the results as a tuplestore rather than
via value-per-call mode.
There are half a dozen other built-in SRFs with similar problems,
but let's fix this one to start with, just to see if the buildfarm
finds anything wrong with the code.
In passing, fix bogus error report for stat() failure: it was
whining about the directory when it should be fingering the
individual file. Doubtless a copy-and-paste error.
Back-patch to v10 where this function was added.
Justin Pryzby, with cosmetic tweaks and test cases by me
Discussion: https://postgr.es/m/
20200308173103.GC1357@telsasoft.com
Peter Eisentraut [Wed, 11 Mar 2020 15:36:40 +0000 (16:36 +0100)]
Refactor ps_status.c API
The init_ps_display() arguments were mostly lies by now, so to match
typical usage, just use one argument and let the caller assemble it
from multiple sources if necessary. The only user of the additional
arguments is BackendInitialize(), which was already doing string
assembly on the caller side anyway.
Remove the second argument of set_ps_display() ("force") and just
handle that in init_ps_display() internally.
BackendInitialize() also used to set the initial status as
"authentication", but that was very far from where authentication
actually happened. So now it's set to "initializing" and then
"authentication" just before the actual call to
ClientAuthentication().
Reviewed-by: Julien Rouhaud <rjuju123@gmail.com>
Reviewed-by: Kuntal Ghosh <kuntalghosh.2007@gmail.com>
Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/
c65e5196-4f04-4ead-9353-
6088c19615a3@2ndquadrant.com
Alvaro Herrera [Wed, 11 Mar 2020 14:04:59 +0000 (11:04 -0300)]
Avoid duplicates in ALTER ... DEPENDS ON EXTENSION
If the command is attempted for an extension that the object already
depends on, silently do nothing.
In particular, this means that if a database containing multiple such
entries is dumped, the restore will silently do the right thing and
record just the first one. (At least, in a world where pg_dump does
dump such entries -- which it doesn't currently, but it will.)
Backpatch to 9.6, where this kind of dependency was introduced.
Reviewed-by: Ibrar Ahmed, Tom Lane (offlist)
Discussion: https://postgr.es/m/
20200217225333.GA30974@alvherre.pgsql
Peter Eisentraut [Wed, 11 Mar 2020 12:51:55 +0000 (13:51 +0100)]
Clean up order in miscinit.c a bit
The code around InitPostmasterChild() from commit
31c453165b5 somehow
ended up in the middle of a block of code related to "User ID state".
Move it into its own block instead.
Peter Eisentraut [Wed, 11 Mar 2020 09:58:02 +0000 (10:58 +0100)]
Remove HAVE_WORKING_LINK
Previously, hard links were not used on Windows and Cygwin, but they
support them just fine in currently supported OS versions, so we can
use them there as well.
Since all supported platforms now support hard links, we can remove
the alternative code paths.
Rename durable_link_or_rename() to durable_rename_excl() to make the
purpose more clear without referencing the implementation details.
Discussion: https://www.postgresql.org/message-id/flat/
72fff73f-dc9c-4ef4-83e8-
d2e60c98df48%402ndquadrant.com
Alexander Korotkov [Wed, 11 Mar 2020 09:00:31 +0000 (12:00 +0300)]
Improve checking of child pages in contrib/amcheck.
This commit eliminates lossiness in check for missing parent downlinks in
B-tree. Instead of collecting lossy bitmap, we check for missing downlinks
while visiting child pages referenced by downlinks of target level. We
traverse from previous child page to the subsequent child page by right links.
Intermediate pages are candidates to have lost parent downlinks.
Also this commit introduces matching of child high key to the pivot key of
it's parent.
Discussion: https://postgr.es/m/CAPpHfduoF-c4RhOyOm%3D4-Y367%2B8txq9Q6iM_ty0OYc8si1Abww%40mail.gmail.com
Author: Alexander Korotkov
Reviewed-by: Peter Geoghegan
Peter Geoghegan [Wed, 11 Mar 2020 01:03:56 +0000 (18:03 -0700)]
Remove stray parenthesis in nbtree.h.
Oversight in commit
0d861bbb702.
Peter Geoghegan [Wed, 11 Mar 2020 00:25:47 +0000 (17:25 -0700)]
nbtree: Move fastpath NULL descent stack assertion.
Commit
074251db added an assertion that verified the fastpath/rightmost
page insert optimization's assumption about free space: There should
always be enough free space on the page to insert the new item without
splitting the page. Otherwise, we end up using the "concurrent root
page split" phony/fake stack path in _bt_insert_parent(). This does not
lead to incorrect behavior, but it is likely to be far slower than
simply using the regular _bt_search() path. The assertion catches
serious performance bugs that would probably take a long time to detect
any other way.
It seems much more natural to make this assertion just before the point
that we generate a fake/phony descent stack. Move the assert there.
This also makes _bt_insertonpg() a bit more readable.
Tom Lane [Tue, 10 Mar 2020 21:34:01 +0000 (17:34 -0400)]
Marginal comments and docs cleanup.
Fix up some imprecise comments and poor markup from
ba79cb5dc. Also try
to convert the documentation of log_min_duration_sample and friends into
passable English.
Peter Geoghegan [Tue, 10 Mar 2020 21:15:41 +0000 (14:15 -0700)]
nbtree: Demote minus infinity "can't happen" error.
Only a very basic logic bug in a _bt_insertonpg() caller could lead to a
violation of this invariant. Besides, any newitemoff used for an
internal page is sanitized using other "can't happen" errors in
_bt_getstackbuf() or its callers, before _bt_insertonpg() even gets
called.
Also, move the error/assertion from the insert-without-split path of
_bt_insertonpg() to the top of the same function. There is no reason
why this invariant only applies to insertions that happen to not result
in a page split; cover every insertion. The assertion naturally belongs
next to the existing generic assertions that document relatively
high-level invariants for the item being inserted.
Tom Lane [Tue, 10 Mar 2020 18:54:00 +0000 (14:54 -0400)]
Ensure that CREATE TABLE LIKE copies any NO INHERIT constraint property.
Since the documentation about LIKE doesn't say that a copied constraint
has properties different from the original, it seems that ignoring
a NO INHERIT property doesn't meet the principle of least surprise.
So make it copy that.
(Note, however, that we still don't copy a NOT VALID property;
CREATE TABLE offers no way to do that, plus it seems pointless.)
Arguably this is a bug fix; but no back-patch, as it seems barely
possible somebody is depending on the current behavior.
Ildar Musin and Chris Travers; reviewed by Amit Langote and myself
Discussion: https://postgr.es/m/CAONYFtMC6C+3AWCVp7Yd8H87Zn0GxG1_iQG6_bQKbaqYZY0=-g@mail.gmail.com
Tom Lane [Tue, 10 Mar 2020 16:46:07 +0000 (12:46 -0400)]
Avoid portability problem introduced in
0a42a2e9c.
Apparently not all shells handle nested quotes quite the same.
But we don't need the inner double quotes in this case, so just
drop them.
Discussion: https://postgr.es/m/
50ecb345-4dc5-1f7d-64ca-
7018195fcc8d@2ndquadrant.com