]> granicus.if.org Git - postgresql/log
postgresql
5 years agoIn the planner, replace an empty FROM clause with a dummy RTE.
Tom Lane [Mon, 28 Jan 2019 22:54:10 +0000 (17:54 -0500)]
In the planner, replace an empty FROM clause with a dummy RTE.

The fact that "SELECT expression" has no base relations has long been a
thorn in the side of the planner.  It makes it hard to flatten a sub-query
that looks like that, or is a trivial VALUES() item, because the planner
generally uses relid sets to identify sub-relations, and such a sub-query
would have an empty relid set if we flattened it.  prepjointree.c contains
some baroque logic that works around this in certain special cases --- but
there is a much better answer.  We can replace an empty FROM clause with a
dummy RTE that acts like a table of one row and no columns, and then there
are no such corner cases to worry about.  Instead we need some logic to
get rid of useless dummy RTEs, but that's simpler and covers more cases
than what was there before.

For really trivial cases, where the query is just "SELECT expression" and
nothing else, there's a hazard that adding the extra RTE makes for a
noticeable slowdown; even though it's not much processing, there's not
that much for the planner to do overall.  However testing says that the
penalty is very small, close to the noise level.  In more complex queries,
this is able to find optimizations that we could not find before.

The new RTE type is called RTE_RESULT, since the "scan" plan type it
gives rise to is a Result node (the same plan we produced for a "SELECT
expression" query before).  To avoid confusion, rename the old ResultPath
path type to GroupResultPath, reflecting that it's only used in degenerate
grouping cases where we know the query produces just one grouped row.
(It wouldn't work to unify the two cases, because there are different
rules about where the associated quals live during query_planner.)

Note: although this touches readfuncs.c, I don't think a catversion
bump is required, because the added case can't occur in stored rules,
only plans.

Patch by me, reviewed by David Rowley and Mark Dilger

Discussion: https://postgr.es/m/15944.1521127664@sss.pgh.pa.us

5 years agoInstall JIT related headers.
Andres Freund [Mon, 28 Jan 2019 21:51:12 +0000 (13:51 -0800)]
Install JIT related headers.

There's no reason not to install these, and jit.h can be useful for
users of e.g. planner hooks.

Author: Donald Dong
Reviewed-By: Andres Freund
Discussion: https://postgr.es/m/296D405F-7F95-49F1-B565-389D6AA78505@csumb.edu
Backpatch: 11-, where JIT compilation was introduced

5 years agoMove page initialization from RelationAddExtraBlocks() to use.
Andres Freund [Mon, 28 Jan 2019 21:15:11 +0000 (13:15 -0800)]
Move page initialization from RelationAddExtraBlocks() to use.

Previously we initialized pages when bulk extending in
RelationAddExtraBlocks(). That has a major disadvantage: It ties
RelationAddExtraBlocks() to heap, as other types of storage are likely
to need different amounts of special space, have different amount of
free space (previously determined by PageGetHeapFreeSpace()).

That we're relying on initializing pages, but not WAL logging the
initialization, also means the risk for getting
"WARNING:  relation \"%s\" page %u is uninitialized --- fixing"
style warnings in vacuums after crashes/immediate shutdowns, is
considerably higher. The warning sounds much more serious than what
they are.

Fix those two issues together by not initializing pages in
RelationAddExtraPages() (but continue to do so in
RelationGetBufferForTuple(), which is linked much more closely to
heap), and accepting uninitialized pages as normal in
vacuumlazy.c. When vacuumlazy encounters an empty page it now adds it
to the FSM, but does nothing else.  We chose to not issue a debug
message, much less a warning in that case - it seems rarely useful,
and quite likely to scare people unnecessarily.

For now empty pages aren't added to the VM, because standbys would not
re-discover such pages after a promotion. In contrast to other sources
for empty pages, there's no corresponding WAL records triggering FSM
updates during replay.

Author: Andres Freund
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/20181219083945.6khtgm36mivonhva@alap3.anarazel.de

5 years agopsql: Remove unused tab completion query
Peter Eisentraut [Mon, 28 Jan 2019 21:02:45 +0000 (22:02 +0100)]
psql: Remove unused tab completion query

This was used for the old CLUSTER syntax, has been unused since
e55c8e36ae44677dca4420bed07ad09d191fdf6c.

5 years agodoc: Add link from sslinfo to pg_stat_ssl
Peter Eisentraut [Mon, 28 Jan 2019 13:28:36 +0000 (14:28 +0100)]
doc: Add link from sslinfo to pg_stat_ssl

Reviewed-by: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
Discussion: https://www.postgresql.org/message-id/flat/398754d8-6bb5-c5cf-e7b8-22e5f0983caf@2ndquadrant.com/

5 years agoAdd tab completion for ALTER INDEX ALTER COLUMN in psql
Michael Paquier [Mon, 28 Jan 2019 06:30:14 +0000 (15:30 +0900)]
Add tab completion for ALTER INDEX ALTER COLUMN in psql

The completion here consists of attribute numbers, which is specific to
this grammar.

Author: Tatsuro Yamada
Reviewed-by: Peter Eisentraut
Discussion: https://portgr.es/m/b58a78fa-81ce-186f-f0bc-c1aa93c46cbf@lab.ntt.co.jp

5 years agoRevert "Avoid creation of the free space map for small heap relations."
Amit Kapila [Mon, 28 Jan 2019 06:01:44 +0000 (11:31 +0530)]
Revert "Avoid creation of the free space map for small heap relations."

This reverts commit ac88d2962a96a9c7e83d5acfc28fe49a72812086.

5 years agoAvoid creation of the free space map for small heap relations.
Amit Kapila [Mon, 28 Jan 2019 02:44:06 +0000 (08:14 +0530)]
Avoid creation of the free space map for small heap relations.

Previously, all heaps had FSMs. For very small tables, this means that the
FSM took up more space than the heap did. This is wasteful, so now we
refrain from creating the FSM for heaps with 4 pages or fewer. If the last
known target block has insufficient space, we still try to insert into some
other page before giving up and extending the relation, since doing
otherwise leads to table bloat. Testing showed that trying every page
penalized performance slightly, so we compromise and try every other page.
This way, we visit at most two pages. Any pages with wasted free space
become visible at next relation extension, so we still control table bloat.
As a bonus, directly attempting one or two pages can even be faster than
consulting the FSM would have been.

Once the FSM is created for a heap we don't remove it even if somebody
deletes all the rows from the corresponding relation.  We don't think it is
a useful optimization as it is quite likely that relation will again grow
to the same size.

Author: John Naylor with design inputs and some code contribution by Amit Kapila
Reviewed-by: Amit Kapila
Tested-by: Mithun C Y
Discussion: https://www.postgresql.org/message-id/CAJVSVGWvB13PzpbLEecFuGFc5V2fsO736BsdTakPiPAcdMM5tQ@mail.gmail.com

5 years agoIn bootstrap mode, don't allow the creation of files if they don't already
Amit Kapila [Mon, 28 Jan 2019 02:21:02 +0000 (07:51 +0530)]
In bootstrap mode, don't allow the creation of files if they don't already
exist.

In commit's b9d01fe288 and 3908473c80, we have added some code where we
allowed the creation of files during mdopen even if they didn't exist
during the bootstrap mode.  The later commit obviates the need for same.

This was harmless code till now but with an upcoming feature where we don't
allow to create FSM for small tables, this will needlessly create FSM
files.

Author: John Naylor
Reviewed-by: Amit Kapila
Discussion: https://www.postgresql.org/message-id/CAJVSVGWvB13PzpbLEecFuGFc5V2fsO736BsdTakPiPAcdMM5tQ@mail.gmail.com
    https://www.postgresql.org/message-id/CAA4eK1KsET6sotf+rzOTQfb83pzVEzVhbQi1nxGFYVstVWXUGw@mail.gmail.com

5 years agoAdd TAP tests for vacuumdb with column lists
Michael Paquier [Sun, 27 Jan 2019 13:25:48 +0000 (22:25 +0900)]
Add TAP tests for vacuumdb with column lists

vacuumdb generates by itself SQL queries to run ANALYZE or VACUUM on the
backend, but we never actually checked for query patterns with column
lists defined.

Author: Michael Paquier
Reviewed-by: Nathan Bossart
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com

5 years agoAllow for yet another crash symptom in 013_crash_restart.pl.
Tom Lane [Sun, 27 Jan 2019 03:12:48 +0000 (22:12 -0500)]
Allow for yet another crash symptom in 013_crash_restart.pl.

Given the right timing, psql could emit "connection to server was lost"
rather than one of the other messages that this test script checked for.
It looks like commit 4247db625 may have made this more likely, but
I don't really believe it was impossible before then.  Rather than
stress about it, just add that spelling as one of the crash-successfully-
detected cases.

Discussion: https://postgr.es/m/19344.1548554028@sss.pgh.pa.us

5 years agoChange function call information to be variable length.
Andres Freund [Sat, 26 Jan 2019 22:17:52 +0000 (14:17 -0800)]
Change function call information to be variable length.

Before this change FunctionCallInfoData, the struct arguments etc for
V1 function calls are stored in, always had space for
FUNC_MAX_ARGS/100 arguments, storing datums and their nullness in two
arrays.  For nearly every function call 100 arguments is far more than
needed, therefore wasting memory. Arg and argnull being two separate
arrays also guarantees that to access a single argument, two
cachelines have to be touched.

Change the layout so there's a single variable-length array with pairs
of value / isnull. That drastically reduces memory consumption for
most function calls (on x86-64 a two argument function now uses
64bytes, previously 936 bytes), and makes it very likely that argument
value and its nullness are on the same cacheline.

Arguments are stored in a new NullableDatum struct, which, due to
padding, needs more memory per argument than before. But as usually
far fewer arguments are stored, and individual arguments are cheaper
to access, that's still a clear win.  It's likely that there's other
places where conversion to NullableDatum arrays would make sense,
e.g. TupleTableSlots, but that's for another commit.

Because the function call information is now variable-length
allocations have to take the number of arguments into account. For
heap allocations that can be done with SizeForFunctionCallInfoData(),
for on-stack allocations there's a new LOCAL_FCINFO(name, nargs) macro
that helps to allocate an appropriately sized and aligned variable.

Some places with stack allocation function call information don't know
the number of arguments at compile time, and currently variably sized
stack allocations aren't allowed in postgres. Therefore allow for
FUNC_MAX_ARGS space in these cases. They're not that common, so for
now that seems acceptable.

Because of the need to allocate FunctionCallInfo of the appropriate
size, older extensions may need to update their code. To avoid subtle
breakages, the FunctionCallInfoData struct has been renamed to
FunctionCallInfoBaseData. Most code only references FunctionCallInfo,
so that shouldn't cause much collateral damage.

This change is also a prerequisite for more efficient expression JIT
compilation (by allocating the function call information on the stack,
allowing LLVM to optimize it away); previously the size of the call
information caused problems inside LLVM's optimizer.

Author: Andres Freund
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/20180605172952.x34m5uz6ju6enaem@alap3.anarazel.de

5 years agoFix psql's "\g target" meta-command to work with COPY TO STDOUT.
Tom Lane [Sat, 26 Jan 2019 19:15:42 +0000 (14:15 -0500)]
Fix psql's "\g target" meta-command to work with COPY TO STDOUT.

Previously, \g would successfully execute the COPY command, but
the target specification if any was ignored, so that the data was
always dumped to the regular query output target.  This seems like
a clear bug, so let's not just fix it but back-patch it.

While at it, adjust the documentation for \copy to recommend
"COPY ... TO STDOUT \g foo" as a plausible alternative.

Back-patch to 9.5.  The problem exists much further back, but the
code associated with \g was refactored enough in 9.5 that we'd
need a significantly different patch for 9.4, and it doesn't
seem worth the trouble.

Daniel Vérité, reviewed by Fabien Coelho

Discussion: https://postgr.es/m/15dadc39-e050-4d46-956b-dcc4ed098753@manitou-mail.org

5 years agoMake regression test output locale-independent
Peter Eisentraut [Sat, 26 Jan 2019 08:22:27 +0000 (09:22 +0100)]
Make regression test output locale-independent

In some locales, letters sort before numbers, so change the object
naming to not depend on that.  Introduced by commit
7c079d7417a8f2d4bf5144732e2f85117db9214f.

5 years agoAllow UNLISTEN in hot-standby mode.
Tom Lane [Sat, 26 Jan 2019 02:14:31 +0000 (21:14 -0500)]
Allow UNLISTEN in hot-standby mode.

Since LISTEN is (still) disallowed, UNLISTEN must be a no-op in a
hot-standby session, and so there's no harm in allowing it.  This
change allows client code to not worry about whether it's connected
to a primary or standby server when performing session-state-reset
type activities.  (Note that DISCARD ALL, which includes UNLISTEN,
was already allowed, making it inconsistent to reject UNLISTEN.)

Per discussion, back-patch to all supported versions.

Shay Rojansky, reviewed by Mi Tar

Discussion: https://postgr.es/m/CADT4RqCf2gA_TJtPAjnGzkC3ZiexfBZiLmA-mV66e4UyuVv8bA@mail.gmail.com

5 years agoSimplify restriction handling of two-phase commit for temporary objects
Michael Paquier [Sat, 26 Jan 2019 01:45:23 +0000 (10:45 +0900)]
Simplify restriction handling of two-phase commit for temporary objects

There were two flags used to track the access to temporary tables and
to the temporary namespace of a session which are used to restrict
PREPARE TRANSACTION, however the first control flag is a concept
included in the second.  This removes the flag for temporary table
tracking, keeping around only the one at namespace level.

Author: Michael Paquier
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/20190118053126.GH1883@paquier.xyz

5 years agoSQL comment: remove extra word in heading comment
Bruce Momjian [Fri, 25 Jan 2019 23:57:21 +0000 (18:57 -0500)]
SQL comment:  remove extra word in heading comment

Reported-by: Daniel Gustafsson
Discussion: https://postgr.es/m/431D5BC1-9696-43FA-B54C-39D5503EB753@yesql.se

Backpatch-through: master

5 years agoSplit QTW_EXAMINE_RTES flag into QTW_EXAMINE_RTES_BEFORE/_AFTER.
Tom Lane [Fri, 25 Jan 2019 22:09:45 +0000 (17:09 -0500)]
Split QTW_EXAMINE_RTES flag into QTW_EXAMINE_RTES_BEFORE/_AFTER.

This change allows callers of query_tree_walker() to choose whether
to visit an RTE before or after visiting the contents of the RTE
(i.e., prefix or postfix tree order).  All existing users of
QTW_EXAMINE_RTES want the QTW_EXAMINE_RTES_BEFORE behavior, but
an upcoming patch will want QTW_EXAMINE_RTES_AFTER, and it seems
like a potentially useful change on its own.

Andreas Karlsson (extracted from CTE inlining patch)

Discussion: https://postgr.es/m/8810.1542402910@sss.pgh.pa.us

5 years agoTeach nulltestsel() that system columns are never NULL.
Tom Lane [Fri, 25 Jan 2019 16:44:26 +0000 (11:44 -0500)]
Teach nulltestsel() that system columns are never NULL.

While it's perhaps unlikely that users would write an explicit test
like "ctid IS NULL", this function is also used in range estimation,
and an incorrect answer can throw off the results for tight ranges.
Anyway it's not much code so we might as well do it.

Edmund Horner

Discussion: https://postgr.es/m/CAMyN-kCa3BFUFrCTtQeprxTU1anCd3Pua7zXstGCKq4pXgjukw@mail.gmail.com

5 years agoFix possibly-uninitialized-variable warning from commit 9556aa01c.
Tom Lane [Fri, 25 Jan 2019 16:27:44 +0000 (11:27 -0500)]
Fix possibly-uninitialized-variable warning from commit 9556aa01c.

Heikki's compiler doesn't complain about end_ptr, apparently,
but mine does.

In passing, I failed to resist the temptation to remove the
no-longer-used fldnum variable, and relocate chunk_len's
declaration to a narrower scope.

5 years agoUse single-byte Boyer-Moore-Horspool search even with multibyte encodings.
Heikki Linnakangas [Fri, 25 Jan 2019 14:25:05 +0000 (16:25 +0200)]
Use single-byte Boyer-Moore-Horspool search even with multibyte encodings.

The old implementation first converted the input strings to arrays of
wchars, and performed the conversion on those. However, the conversion is
expensive, and for a large input string, consumes a lot of memory.
Allocating the large arrays also meant that these functions could not be
used on strings larger 1 GB / pg_encoding_max_length() (256 MB for UTF-8).

Avoid the conversion, and instead use the single-byte algorithm even with
multibyte encodings. That can get fooled, if there is a matching byte
sequence in the middle of a multi-byte character, so to eliminate false
positives like that, we verify any matches by walking the string character
by character with pg_mblen(). Also, if the caller needs the position of
the match, as a character-offset, we also need to walk the string to count
the characters.

Performance testing shows that walking the whole string with pg_mblen() is
somewhat slower than converting the whole string to wchars. It's still
often a win, though, because we don't need to do it if there is no match,
and even when there is, we only need to walk up to the point where the
match is, not the whole string. Even in the worst case, there would be
room for optimization: Much of the CPU time in the current loop with
pg_mblen() is function call overhead, and could be improved by inlining
pg_mblen() and/or the encoding-specific mblen() functions. But I didn't
attempt to do that as part of this patch.

Most of the callers of text_position_setup/next functions were actually
not interested in the position of the match, counted in characters. To
cater for them, refactor the text_position_next() interface into two
parts: searching for the next match (text_position_next()), and returning
the current match's position as a pointer (text_position_get_match_ptr())
or as a character offset (text_position_get_match_pos()). Getting the
pointer to the match is a more convenient API for many callers, and with
UTF-8, it allows skipping the character-walking step altogether, because
UTF-8 can't have false matches even when treated like raw byte strings.

Reviewed-by: John Naylor
Discussion: https://www.postgresql.org/message-id/3173d989-bc1c-fc8a-3b69-f24246f73876%40iki.fi

5 years agoFix comments that claimed that mblen() only looks at first byte.
Heikki Linnakangas [Fri, 25 Jan 2019 12:54:38 +0000 (14:54 +0200)]
Fix comments that claimed that mblen() only looks at first byte.

GB18030's mblen() function looks at the first and the second byte of the
multibyte character, to determine its length. copy.c had made the
assumption that mblen() only looks at the first byte, but it turns out to
work out fine, because of the way the GB18030 encoding works. COPY will
see a 4-byte encoded character as two 2-byte encoded characters, which is
enough for COPY's purposes. It cannot mix those up with delimiter or
escaping characters, because only single-byte ASCII characters are
supported as delimiters or escape characters.

Discussion: https://www.postgresql.org/message-id/7704d099-9643-2a55-fb0e-becd64400dcb%40iki.fi

5 years agoAllow generalized expression syntax for partition bounds
Peter Eisentraut [Fri, 25 Jan 2019 10:27:59 +0000 (11:27 +0100)]
Allow generalized expression syntax for partition bounds

Previously, only literals were allowed.  This change allows general
expressions, including functions calls, which are evaluated at the
time the DDL command is executed.

Besides offering some more functionality, it simplifies the parser
structures and removes some inconsistencies in how the literals were
handled.

Author: Kyotaro Horiguchi, Tom Lane, Amit Langote
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/9f88b5e0-6da2-5227-20d0-0d7012beaa1c@lab.ntt.co.jp/

5 years agoRemove _configthreadlocale() calls in ecpg test suite.
Tom Lane [Thu, 24 Jan 2019 22:02:09 +0000 (17:02 -0500)]
Remove _configthreadlocale() calls in ecpg test suite.

This essentially reverts commits a772624b1 and 04fbe0e45, which
added "_configthreadlocale(_ENABLE_PER_THREAD_LOCALE)" calls to the
thread-related ecpg test programs.  That was nothing but a hack,
because we shouldn't expect that ecpg-using applications have
done that for us; and now that we've inserted such calls into
ecpglib, the tests should still pass without it.

(If they don't, it would be good to know that.)

HEAD only; there seems no big need to change this in the
back branches.

Discussion: https://postgr.es/m/22937.1548307384@sss.pgh.pa.us

5 years agoRemove infinite-loop hazards in ecpg test suite.
Tom Lane [Thu, 24 Jan 2019 21:46:55 +0000 (16:46 -0500)]
Remove infinite-loop hazards in ecpg test suite.

A report from Andrew Dunstan showed that an ecpglib breakage that
causes repeated query failures could lead to infinite loops in some
ecpg test scripts, because they contain "while(1)" loops with no
exit condition other than successful test completion.  That might
be all right for manual testing, but it seems entirely unacceptable
for automated test environments such as our buildfarm.  We don't
want buildfarm owners to have to intervene manually when a test
goes wrong.

To fix, just change all those while(1) loops to exit after at most
100 iterations (which is more than any of them expect to iterate).
This seems sufficient since we'd see discrepancies in the test output
if any loop executed the wrong number of times.

I tested this by dint of intentionally breaking ecpg_do_prologue
to always fail, and verifying that the tests still got to completion.

Back-patch to all supported branches, since the whole point of this
exercise is to protect the buildfarm against future mistakes.

Discussion: https://postgr.es/m/18693.1548302004@sss.pgh.pa.us

5 years agoPL/pgSQL: Add statement ID to statement structures
Peter Eisentraut [Thu, 24 Jan 2019 21:23:12 +0000 (22:23 +0100)]
PL/pgSQL: Add statement ID to statement structures

This can be used by a profiler as the index for an array of
per-statement metrics.

Author: Pavel Stehule <pavel.stehule@gmail.com>
Reviewed-by: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Discussion: https://www.postgresql.org/message-id/flat/CAFj8pRDRCjN6rpM9ZccU7Ta_afsNX7mg9=n34F+r445Nt9v2tA@mail.gmail.com/

5 years agoFix whitespace
Peter Eisentraut [Thu, 24 Jan 2019 20:58:37 +0000 (21:58 +0100)]
Fix whitespace

5 years agoFix droppability of constraints upon partition detach
Alvaro Herrera [Thu, 24 Jan 2019 17:09:56 +0000 (14:09 -0300)]
Fix droppability of constraints upon partition detach

We were failing to set conislocal correctly for constraints in
partitions after partition detach, leading to those constraints becoming
undroppable.  Fix by setting the flag correctly.  Existing databases
might contain constraints with the conislocal wrongly set to false, for
partitions that were detached; this situation should be fixable by
applying an UPDATE on pg_constraint to set conislocal true.  This
problem should otherwise be innocuous and should disappear across a
dump/restore or pg_upgrade.

Secondarily, when constraint drop was attempted in a partitioned table,
ATExecDropConstraint would try to recurse to partitions after doing
performDeletion() of the constraint in the partitioned table itself; but
since the constraint in the partitions are dropped by the initial call
of performDeletion() (because of following dependencies), the recursion
step would fail since it would not find the constraint, causing the
whole operation to fail.  Fix by preventing recursion.

Reported-by: Amit Langote
Diagnosed-by: Amit Langote
Author: Amit Langote, Álvaro Herrera
Discussion: https://postgr.es/m/f2b8ead5-4131-d5a8-8016-2ea0a31250af@lab.ntt.co.jp

5 years agoFix portability problem in pgbench.
Tom Lane [Thu, 24 Jan 2019 16:31:54 +0000 (11:31 -0500)]
Fix portability problem in pgbench.

The pgbench regression test supposed that srandom() with a specific value
would result in deterministic output from random(), as required by POSIX.
It emerges however that OpenBSD is too smart to be constrained by mere
standards, so their random() emits nondeterministic output anyway.
While a workaround does exist, what seems like a better fix is to stop
relying on the platform's srandom()/random() altogether, so that what
you get from --random-seed=N is not merely deterministic but platform
independent.  Hence, use a separate pg_jrand48() random sequence in
place of random().

Also adjust the regression test case that's supposed to detect
nondeterminism so that it's more likely to detect it; the original
choice of random_zipfian parameter tended to produce the same output
all the time even if the underlying behavior wasn't deterministic.

In passing, improve pgbench's docs about random_zipfian().

Back-patch to v11 where this code was introduced.

Fabien Coelho and Tom Lane

Discussion: https://postgr.es/m/4615.1547792324@sss.pgh.pa.us

5 years agoSimplify coding to detach constraints when detaching partition
Alvaro Herrera [Thu, 24 Jan 2019 14:18:35 +0000 (11:18 -0300)]
Simplify coding to detach constraints when detaching partition

The original coding was too baroque and led to an use-after-release
mistake, noticed by buildfarm member prion.

Discussion: https://postgr.es/m/21693.1548305934@sss.pgh.pa.us

5 years agopostgres_fdw: Account for tlist eval costs in estimate_path_cost_size().
Etsuro Fujita [Thu, 24 Jan 2019 07:49:17 +0000 (16:49 +0900)]
postgres_fdw: Account for tlist eval costs in estimate_path_cost_size().

Previously, estimate_path_cost_size() didn't account for tlist eval
costs, except when costing a foreign-grouping path using local
statistics, but such costs should be accounted for when costing that path
using remote estimates, because some of the tlist expressions might be
evaluated locally.  Also, such costs should be accounted for in the case
of a foreign-scan or foreign-join path, because the tlist might contain
PlaceHolderVars, which postgres_fdw currently evaluates locally.

This also fixes an oversight in my commit f8f6e44676.

Like that commit, apply this to HEAD only to avoid destabilizing existing
plan choices.

Author: Etsuro Fujita
Discussion: https://postgr.es/m/5BFD3EAD.2060301%40lab.ntt.co.jp

5 years agoBlind attempt to fix _configthreadlocale() failures on MinGW.
Tom Lane [Thu, 24 Jan 2019 03:46:45 +0000 (22:46 -0500)]
Blind attempt to fix _configthreadlocale() failures on MinGW.

Apparently, some builds of MinGW contain a version of
_configthreadlocale() that always returns -1, indicating failure.
Rather than treating that as a curl-up-and-die condition, soldier on
as though the function didn't exist.  This leaves us without thread
safety on such MinGW versions, but we didn't have it anyway.

Discussion: https://postgr.es/m/d06a16bc-52d6-9f0d-2379-21242d7dbe81@2ndQuadrant.com

5 years agoDetach constraints when partitions are detached
Alvaro Herrera [Thu, 24 Jan 2019 02:57:46 +0000 (23:57 -0300)]
Detach constraints when partitions are detached

I (Álvaro) forgot to do this in eb7ed3f30634, leading to undroppable
constraints after partitions are detached.  Repair.

Reported-by: Amit Langote
Author: Amit Langote
Discussion: https://postgr.es/m/c1c9b688-b886-84f7-4048-1e4ebe9b1d06@lab.ntt.co.jp

5 years agoRemove argument isprimary from index_build()
Michael Paquier [Wed, 23 Jan 2019 22:57:09 +0000 (07:57 +0900)]
Remove argument isprimary from index_build()

The flag was introduced in 3fdeb18, but f66e8bf actually forgot to
finish the cleanup as index_update_stats() has simplified its
interface.

Author: Michael Paquier
Discussion: https://postgr.es/m/20190122080852.GB3873@paquier.xyz

5 years agoFix misc typos in comments.
Heikki Linnakangas [Wed, 23 Jan 2019 11:39:00 +0000 (13:39 +0200)]
Fix misc typos in comments.

Spotted mostly by Fabien Coelho.

Discussion: https://www.postgresql.org/message-id/alpine.DEB.2.21.1901230947050.16643@lancre

5 years agoFix typo in pgbench.c
Michael Paquier [Wed, 23 Jan 2019 05:57:29 +0000 (14:57 +0900)]
Fix typo in pgbench.c

Author: Moon, Insung
Discussion: https://postgr.es/m/008001d4b2db$1f772170$5e656450$@lab.ntt.co.jp

5 years agoDoc: fix typo in URL of OASIS group web site.
Tatsuo Ishii [Wed, 23 Jan 2019 04:06:45 +0000 (13:06 +0900)]
Doc: fix typo in URL of OASIS group web site.

In other places that has been changed from http://www.oasis-open.org/
https://www.oasis-open.org/ but there's a place where the change was
missed.
Discussion: https://postgr.es/m/20190121.222844.399814306477973879.t-ishii%40sraoss.co.jp

5 years agoMake vacuumdb test regex more modular for its query output
Michael Paquier [Wed, 23 Jan 2019 00:57:19 +0000 (09:57 +0900)]
Make vacuumdb test regex more modular for its query output

This is in preparation for always using a catalog query to discover
tables, where the ANALYZE and VACUUM queries get completed with relation
names.

Author: Nathan Bossart
Discussion: https://postgr.es/m/20190122060730.GD8719@paquier.xyz

5 years agoFix handling of volatile expressions in COPY FROM ... WHERE
Tomas Vondra [Tue, 22 Jan 2019 22:11:17 +0000 (23:11 +0100)]
Fix handling of volatile expressions in COPY FROM ... WHERE

The checking for calls to volatile functions in the COPY FROM ... WHERE
expression was treating all WHERE clauses as if containing such calls.
While that does not produce incorrect results, this disables batching
which may result in significant performance regression.

Discussion: https://www.postgresql.org/message-id/flat/CALAY4q_DdpWDuB5-Zyi-oTtO2uSk8pmy+dupiRe3AvAc++1imA@mail.gmail.com

5 years agollvm: Fix file-ending in IDENTIFICATION comments.
Andres Freund [Tue, 22 Jan 2019 19:46:59 +0000 (11:46 -0800)]
llvm: Fix file-ending in IDENTIFICATION comments.

Author: Amit Langote
Discussion: https://postgr.es/m/9a54dcef-c799-ce89-2e47-0a7fc12d5fc2@lab.ntt.co.jp
Backpatch: 11-, where llvm was introduced.

5 years agoAdjust documentation for vacuumdb --disable-page-skipping
Michael Paquier [Tue, 22 Jan 2019 02:21:07 +0000 (11:21 +0900)]
Adjust documentation for vacuumdb --disable-page-skipping

This makes the description more consistent with the other options, and
the mapping with VACUUM is intuitive.

Author: Nathan Bossart
Discussion: https://postgr.es/m/FFE5373C-E26A-495B-B5C8-911EC4A41C5E@amazon.com

5 years agoRename RelationData.rd_amroutine to rd_indam.
Andres Freund [Tue, 22 Jan 2019 01:36:55 +0000 (17:36 -0800)]
Rename RelationData.rd_amroutine to rd_indam.

The upcoming table AM support makes rd_amroutine to generic, as its
only about index AMs. The new name makes that clear, and is shorter to
boot.

Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de

5 years agoRephrase references to "time qualification".
Andres Freund [Tue, 22 Jan 2019 01:03:15 +0000 (17:03 -0800)]
Rephrase references to "time qualification".

Now that the relevant code has, for other reasons, moved out of
tqual.[ch], it seems time to refer to visiblity rather than time
qualification.

Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de

5 years agoMove remaining code from tqual.[ch] to heapam.h / heapam_visibility.c.
Andres Freund [Tue, 22 Jan 2019 01:03:15 +0000 (17:03 -0800)]
Move remaining code from tqual.[ch] to heapam.h / heapam_visibility.c.

Given these routines are heap specific, and that there will be more
generic visibility support in via table AM, it makes sense to move the
prototypes to heapam.h (routines like HeapTupleSatisfiesVacuum will
not be exposed in a generic fashion, because they are too storage
specific).

Similarly, the code in tqual.c is specific to heap, so moving it into
access/heap/ makes sense.

Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de

5 years agoMove generic snapshot related code from tqual.h to snapmgr.h.
Andres Freund [Tue, 22 Jan 2019 01:03:15 +0000 (17:03 -0800)]
Move generic snapshot related code from tqual.h to snapmgr.h.

The code in tqual.c is largely heap specific. Due to the upcoming
pluggable storage work, it therefore makes sense to move it into
access/heap/ (as the file's header notes, the tqual name isn't very
good).

But the various statically allocated snapshot and snapshot
initialization functions are now (see previous commit) generic and do
not depend on functions declared in tqual.h anymore. Therefore move.
Also move XidInMVCCSnapshot as that's useful for future AMs, and
already used outside of tqual.c.

Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de

5 years agoChange snapshot type to be determined by enum rather than callback.
Andres Freund [Tue, 22 Jan 2019 01:03:15 +0000 (17:03 -0800)]
Change snapshot type to be determined by enum rather than callback.

This is in preparation for allowing the same snapshot be used for
different table AMs. With the current callback based approach we would
need one callback for each supported AM, which clearly would not be
extensible.  Thus add a new Snapshot->snapshot_type field, and move
the dispatch into HeapTupleSatisfiesVisibility() (which is now a
function). Later work will then dispatch calls to
HeapTupleSatisfiesVisibility() and other AMs visibility functions
depending on the type of the table.  The central SnapshotType enum
also seems like a good location to centralize documentation about the
intended behaviour of various types of snapshots.

As tqual.h isn't included by bufmgr.h any more (as HeapTupleSatisfies*
isn't referenced by TestForOldSnapshot() anymore) a few files now need
to include it directly.

Author: Andres Freund, loosely based on earlier work by Haribabu Kommi
Discussion:
    https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de
    https://postgr.es/m/20160812231527.GA690404@alvherre.pgsql

5 years agoRemove useless bms_copy step in RelationGetIndexAttrBitmap.
Tom Lane [Mon, 21 Jan 2019 23:33:32 +0000 (18:33 -0500)]
Remove useless bms_copy step in RelationGetIndexAttrBitmap.

Seems to be from a bad case of copy-and-paste-itis in commit 665d1fad9.
It wouldn't be quite so annoying if it didn't contradict the comment
half a dozen lines above.

David Rowley

Discussion: https://postgr.es/m/CAKJS1f95Dyf8Qkdz4W+PbCmT-HTb54tkqUCC8isa2RVgSJ_pXQ@mail.gmail.com

5 years agoCreate action triggers when partitions are detached
Alvaro Herrera [Mon, 21 Jan 2019 22:59:07 +0000 (19:59 -0300)]
Create action triggers when partitions are detached

Detaching a partition from a partitioned table that's constrained by
foreign keys requires additional action triggers on the referenced side;
otherwise, DELETE/UPDATE actions there fail to notice rows in the table
that was partition, and so are incorrectly allowed through.  With this
commit, those triggers are now created.  Conversely, when a table that
has a foreign key is attached as a partition to a table that also has
the same foreign key, those action triggers are no longer needed, so we
remove them.

Add a minimal test case verifying (part of) this.

Authors: Amit Langote, Álvaro Herrera
Discussion: https://postgr.es/m/f2b8ead5-4131-d5a8-8016-2ea0a31250af@lab.ntt.co.jp

5 years agoFlush relcache entries when their FKs are meddled with
Alvaro Herrera [Mon, 21 Jan 2019 22:34:11 +0000 (19:34 -0300)]
Flush relcache entries when their FKs are meddled with

Back in commit 100340e2dcd0, we made relcache entries keep lists of the
foreign keys applying to the relation -- but we forgot to update
CacheInvalidateHeapTuple to flush those entries when new FKs got created
or existing ones updated/deleted.  No bugs appear to have been reported
that would be explained by this ommission, but I noticed the problem
while working on an unrelated bugfix which clearly showed it.  Fix by
adding relcache flush on relevant foreign key changes.

Backpatch to 9.6, like the aforementioned commit.

Discussion: https://postgr.es/m/201901211927.7mmhschxlejh@alvherre.pgsql
Reviewed-by: Tom Lane
5 years agoSecond try at fixing ecpglib thread-safety problem.
Tom Lane [Mon, 21 Jan 2019 21:17:10 +0000 (16:17 -0500)]
Second try at fixing ecpglib thread-safety problem.

While Windows (allegedly) has _configthreadlocale() pretty far back,
it seems MinGW didn't acquire support for that till more recently.
Fortunately, we can use an autoconf probe on that toolchain,
instead of guessing whether it's there.  (Hm, I wonder whether Cygwin
will need this also.)

Per buildfarm.

Discussion: https://postgr.es/m/20190121193512.tdmcnic2yjxlufaw@alap3.anarazel.de

5 years agoFix "Remove superfluous tqual.h includes" by adding back one include.
Andres Freund [Mon, 21 Jan 2019 20:59:31 +0000 (12:59 -0800)]
Fix "Remove superfluous tqual.h includes" by adding back one include.

I removed one include too many in e7cc78ad43eb, not sure why that
escaped my test script.

Author: Andres Freund

5 years agoFix sepgsql regression test.
Tom Lane [Mon, 21 Jan 2019 20:39:08 +0000 (15:39 -0500)]
Fix sepgsql regression test.

Message order in the expected output changes due to commit f1ad067fc.
Per buildfarm.

Discussion: https://postgr.es/m/20190121201134.dyx6anto6akflh5d@alap3.anarazel.de

5 years agoRemove superfluous tqual.h includes.
Andres Freund [Mon, 21 Jan 2019 20:15:02 +0000 (12:15 -0800)]
Remove superfluous tqual.h includes.

Most of these had been obsoleted by 568d4138c / the SnapshotNow
removal.

This is is preparation for moving most of tqual.[ch] into either
snapmgr.h or heapam.h, which in turn is in preparation for pluggable
table AMs.

Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de

5 years agoReplace uses of heap_open et al with the corresponding table_* function.
Andres Freund [Mon, 21 Jan 2019 18:32:19 +0000 (10:32 -0800)]
Replace uses of heap_open et al with the corresponding table_* function.

Author: Andres Freund
Discussion: https://postgr.es/m/20190111000539.xbv7s6w7ilcvm7dp@alap3.anarazel.de

5 years agoReplace heapam.h includes with {table, relation}.h where applicable.
Andres Freund [Mon, 21 Jan 2019 18:18:20 +0000 (10:18 -0800)]
Replace heapam.h includes with {table, relation}.h where applicable.

A lot of files only included heapam.h for relation_open, heap_open etc
- replace the heapam.h include in those files with the narrower
header.

Author: Andres Freund
Discussion: https://postgr.es/m/20190111000539.xbv7s6w7ilcvm7dp@alap3.anarazel.de

5 years agoIntroduce access/{table.h, relation.h}, for generic functions from heapam.h.
Andres Freund [Mon, 21 Jan 2019 18:14:09 +0000 (10:14 -0800)]
Introduce access/{table.h, relation.h}, for generic functions from heapam.h.

access/heapam contains functions that are very storage specific (say
heap_insert() and a lot of lower level functions), and fairly generic
infrastructure like relation_open(), heap_open() etc.  In the upcoming
pluggable storage work we're introducing a layer between table
accesses in general and heapam, to allow for different storage
methods. For a bit cleaner separation it thus seems advantageous to
move generic functions like the aforementioned to their own headers.

access/relation.h will contain relation_open() etc, and access/table.h
will contain table_open() (formerly known as heap_open()). I've decided
for table.h not to include relation.h, but we might change that at a
later stage.

relation.h already exists in another directory, but the other
plausible name (rel.h) also conflicts. It'd be nice if there were a
non-conflicting name, but nobody came up with a suggestion. It's
possible that the appropriate way to address the naming conflict would
be to rename nodes/relation.h, which isn't particularly well named.

To avoid breaking a lot of extensions that just use heap_open() etc,
table.h has macros mapping the old names to the new ones, and heapam.h
includes relation, table.h.  That also allows to keep the
bulk renaming of existing callers in a separate commit.

Author: Andres Freund
Discussion: https://postgr.es/m/20190111000539.xbv7s6w7ilcvm7dp@alap3.anarazel.de

5 years agoSort the dependent objects before recursing in findDependentObjects().
Tom Lane [Mon, 21 Jan 2019 18:48:07 +0000 (13:48 -0500)]
Sort the dependent objects before recursing in findDependentObjects().

Historically, the notices output by DROP CASCADE tended to come out
in uncertain order, and in some cases you might get different claims
about which object depends on which other one.  This is because we
just traversed the dependency tree in the order in which pg_depend
entries are seen, and nbtree has never promised anything about the
order of equal-keyed index entries.  We've put up with that for years,
hacking regression tests when necessary to prevent them from emitting
unstable output.  However, it's a problem for pending work that will
change nbtree's behavior for equal keys, as that causes unexpected
changes in the regression test results.

Hence, adjust findDependentObjects to sort the results of each
indexscan before processing them.  The sort is on descending OID of
the dependent objects, hence more or less reverse creation order.
While this rule could still result in bogus regression test failures
if an OID wraparound occurred mid-test, that seems unlikely to happen
in any plausible development or packaging-test scenario.

This is enough to ensure output stability for ordinary DROP CASCADE
commands, but not for DROP OWNED BY, because that has a different
code path with the same problem.  We might later choose to sort in
the DROP OWNED BY code as well, but this patch doesn't do so.

I've also not done anything about reverting the existing hacks to
suppress unstable DROP CASCADE output in specific regression tests.
It might be worth undoing those, but it seems like a distinct question.

The first indexscan loop in findDependentObjects is not touched,
meaning there is a hazard of unstable error reports from that too.
However, said hazard is not the fault of that code: it was designed
on the assumption that there could be at most one "owning" object
to complain about, and that assumption does not seem unreasonable.
The recent patch that added the possibility of multiple
DEPENDENCY_INTERNAL_AUTO links broke that assumption, but we should
fix that situation not band-aid around it.  That's a matter for
another patch, though.

Discussion: https://postgr.es/m/12244.1547854440@sss.pgh.pa.us

5 years agoAdd 'id' to Acknowledgments section
Alvaro Herrera [Mon, 21 Jan 2019 17:41:44 +0000 (14:41 -0300)]
Add 'id' to Acknowledgments section

Per note from Erik Rijkers
Discussion: https://postgr.es/m/3db724af16ee009ab7f812a6a1d9354e@xs4all.nl

5 years agoFix ALTER TRIGGER ... RENAME, broken in WITH OIDS removal.
Andres Freund [Mon, 21 Jan 2019 17:12:31 +0000 (09:12 -0800)]
Fix ALTER TRIGGER ... RENAME, broken in WITH OIDS removal.

I (Andres) broke this in 578b229718e.

Author: Rushabh Lathia
Discussion: https://postgr.es/m/CAGPqQf04PywZX3sVQaF6H=oLiW9GJncRW+=e78vTy4MokEWcZw@mail.gmail.com

5 years agoAdjust some more comments for WITH OIDS removal.
Andres Freund [Mon, 21 Jan 2019 17:05:51 +0000 (09:05 -0800)]
Adjust some more comments for WITH OIDS removal.

I missed these in 578b229718e8f.

Author: Andres Freund

5 years agoAvoid thread-safety problem in ecpglib.
Tom Lane [Mon, 21 Jan 2019 17:07:02 +0000 (12:07 -0500)]
Avoid thread-safety problem in ecpglib.

ecpglib attempts to force the LC_NUMERIC locale to "C" while reading
server output, to avoid problems with strtod() and related functions.
Historically it's just issued setlocale() calls to do that, but that
has major problems if we're in a threaded application.  setlocale()
itself is not required by POSIX to be thread-safe (and indeed is not,
on recent OpenBSD).  Moreover, its effects are process-wide, so that
we could cause unexpected results in other threads, or another thread
could change our setting.

On platforms having uselocale(), which is required by POSIX:2008,
we can avoid these problems by using uselocale() instead.  Windows
goes its own way as usual, but we can make it safe by using
_configthreadlocale().  Platforms having neither continue to use the
old code, but that should be pretty much nobody among current systems.

This should get back-patched, but let's see what the buildfarm
thinks of it first.

Michael Meskes and Tom Lane; thanks also to Takayuki Tsunakawa.

Discussion: https://postgr.es/m/31420.1547783697@sss.pgh.pa.us

5 years agoRevert "Fix under-quoted filename pattern in pgbench TAP test."
Tom Lane [Mon, 21 Jan 2019 16:28:03 +0000 (11:28 -0500)]
Revert "Fix under-quoted filename pattern in pgbench TAP test."

This reverts commit 458a1244f1fcf407874482a93b7631ecf5303d6e.
It has portability problems on Windows, which will require
a little bit of research to fix.

Discussion: https://postgr.es/m/20202.1548035461@sss.pgh.pa.us

5 years agoPostpone generating tlists and EC members for inheritance dummy children.
Etsuro Fujita [Mon, 21 Jan 2019 08:12:40 +0000 (17:12 +0900)]
Postpone generating tlists and EC members for inheritance dummy children.

Previously, in set_append_rel_size(), we generated tlists and EC members
for dummy children for possible use by partition-wise join, even if
partition-wise join was disabled or the top parent was not a partitioned
table, but adding such EC members causes noticeable planning speed
degradation for queries with certain kinds of join quals like
"(foo.x + bar.y) = constant" where foo and bar are partitioned tables in
cases where there are lots of dummy children, as the EC members lists
grow huge, especially for the ECs derived from such join quals, which
makes the search for the parent EC members in add_child_rel_equivalences()
very time-consuming.  Postpone the work until such children are actually
involved in a partition-wise join.

Reported-by: Sanyo Capobiango
Analyzed-by: Justin Pryzby and Alvaro Herrera
Author: Amit Langote, with a few additional changes by me
Reviewed-by: Ashutosh Bapat
Backpatch-through: v11 where partition-wise join was added
Discussion: https://postgr.es/m/CAO698qZnrxoZu7MEtfiJmpmUtz3AVYFVnwzR%2BpqjF%3DrmKBTgpw%40mail.gmail.com

5 years agoAllow COPY FROM to filter data using WHERE conditions
Tomas Vondra [Sat, 19 Jan 2019 22:48:16 +0000 (23:48 +0100)]
Allow COPY FROM to filter data using WHERE conditions

Extends the COPY FROM command with a WHERE condition, which allows doing
various types of filtering while importing the data (random sampling,
condition on a data column, etc.).  Until now such filtering required
either preprocessing of the input data, or importing all data and then
filtering in the database. COPY FROM ... WHERE is an easy-to-use and
low-overhead alternative for most simple cases.

Author: Surafel Temesgen
Reviewed-by: Tomas Vondra, Masahiko Sawada, Lim Myungkyu
Discussion: https://www.postgresql.org/message-id/flat/CALAY4q_DdpWDuB5-Zyi-oTtO2uSk8pmy+dupiRe3AvAc++1imA@mail.gmail.com

5 years agoRevert "Add valgrind suppressions for wcsrtombs optimizations"
Tomas Vondra [Sat, 19 Jan 2019 19:49:51 +0000 (20:49 +0100)]
Revert "Add valgrind suppressions for wcsrtombs optimizations"

This reverts commit d3bbc4b96a5b4d055cf636596c6865913a099929.

Per discussion, it's not desirable to add valgrind suppressions for
outside our own code base (e.g. glibc in this case), especially when
the suppressions may be platform-specific. There are better ways to
deal with that, e.g. by providing local suppressions.

Discussion: https://www.postgresql.org/message-id/flat/90ac0452-e907-e7a4-b3c8-15bd33780e62%402ndquadrant.com

5 years agoReplace @postgresql.org with @lists.postgresql.org for mailinglists
Magnus Hagander [Sat, 19 Jan 2019 18:06:35 +0000 (19:06 +0100)]
Replace @postgresql.org with @lists.postgresql.org for mailinglists

Commit c0d0e54084 replaced the ones in the documentation, but missed out
on the ones in the code. Replace those as well, but unlike c0d0e54084,
don't backpatch the code changes to avoid breaking translations.

5 years agoFix outdated comment
Peter Eisentraut [Sat, 19 Jan 2019 08:34:24 +0000 (09:34 +0100)]
Fix outdated comment

The issue the comment is referring to was fixed by
08859bb5c2cebc132629ca838113d27bb31b990c.

5 years agoFix under-quoted filename pattern in pgbench TAP test.
Tom Lane [Fri, 18 Jan 2019 20:23:44 +0000 (15:23 -0500)]
Fix under-quoted filename pattern in pgbench TAP test.

Avoids issues if build directory's pathname contains regex
metacharacters.

Raúl Marín Rodríguez

Discussion: https://postgr.es/m/CAM6_UM6dGdU39PKAC24T+HD9ouy0jLN9vH6163K8QEEzr__iZw@mail.gmail.com

5 years agoUse our own getopt() on OpenBSD.
Tom Lane [Fri, 18 Jan 2019 20:06:26 +0000 (15:06 -0500)]
Use our own getopt() on OpenBSD.

Recent OpenBSD (at least 5.9 and up) has a version of getopt(3)
that will not cope with the "-:" spec we use to accept double-dash
options in postgres.c and postmaster.c.  Admittedly, that's a hack
because POSIX only requires getopt() to allow alphanumeric option
characters.  I have no desire to find another way, however, so
let's just do what we were already doing on Solaris: force use
of our own src/port/getopt.c implementation.

In passing, improve some of the comments around said implementation.

Per buildfarm and local testing.  Back-patch to all supported branches.

Discussion: https://postgr.es/m/30197.1547835700@sss.pgh.pa.us

5 years agoFix creation of duplicate foreign keys on partitions
Alvaro Herrera [Fri, 18 Jan 2019 17:49:40 +0000 (14:49 -0300)]
Fix creation of duplicate foreign keys on partitions

When creating a foreign key in a partitioned table, if some partitions
already have equivalent constraints, we wastefully create duplicates of
the constraints instead of attaching to the existing ones.  That's
inconsistent with the de-duplication that is applied when a table is
attached as a partition.  To fix, reuse the FK-cloning code instead of
having a separate code path.

Backpatch to Postgres 11.  This is a subtle behavior change, but surely
a welcome one since there's no use in having duplicate foreign keys.

Discovered by Álvaro Herrera while thinking about a different problem
reported by Jesper Pedersen (bug #15587).

Author: Álvaro Herrera
Discussion: https://postgr.es/m/201901151935.zfadrzvyof4k@alvherre.pgsql

5 years agoMove CloneForeignKeyConstraints to tablecmds.c
Alvaro Herrera [Fri, 18 Jan 2019 17:49:27 +0000 (14:49 -0300)]
Move CloneForeignKeyConstraints to tablecmds.c

My commit 3de241dba86f introduced some code to create a clone of a
foreign key to a partition, but I put it in pg_constraint.c because it
was too close to the contents of the pg_constraint row.  With the
previous commit that split out the constraint tuple deconstruction into
its own routine, it makes more sense to have the FK-cloning function in
tablecmds.c, mostly because its static subroutine can then be used by a
future bugfix.

My initial posting of this patch had this routine as static in
tablecmds.c, but sadly this function is already part of the Postgres 11
ABI as exported from pg_constraint.c, so keep it as exported also just
to avoid breaking any possible users of it.

5 years agoRefactor duplicate code into DeconstructFkConstraintRow
Alvaro Herrera [Fri, 18 Jan 2019 17:40:13 +0000 (14:40 -0300)]
Refactor duplicate code into DeconstructFkConstraintRow

My commit 3de241dba86f introduced some code (in tablecmds.c) to obtain
data from a pg_constraint row for a foreign key, that already existed in
ri_triggers.c.  Split it out into its own routine in pg_constraint.c,
where it naturally belongs.

No functional code changes, only code movement.

Backpatch to pg11, because a future bugfix is simpler after this.

5 years agoAvoid sometimes printing both tables and their columns in DROP CASCADE.
Tom Lane [Fri, 18 Jan 2019 16:05:11 +0000 (11:05 -0500)]
Avoid sometimes printing both tables and their columns in DROP CASCADE.

A cascaded drop might find independent reasons to drop both a table
and some column of the table (for instance, a schema drop might include
dropping a data type used in some table in the schema).  Depending on
the order of visitation of pg_depend entries, we might report the
table column and the whole table as separate objects-to-be-dropped,
or we might only report the table.  This is confusing and leads to
unstable regression test output, so fix it to report only the table
regardless of visitation order.

Per gripe from Peter Geoghegan.  This is just cosmetic from a user's
standpoint, and we haven't actually seen regression test problems in
practice (yet), so I'll refrain from back-patching.

Discussion: https://postgr.es/m/15908.1547762076@sss.pgh.pa.us

5 years agoRemove obsolete comment
Peter Eisentraut [Fri, 18 Jan 2019 08:48:51 +0000 (09:48 +0100)]
Remove obsolete comment

5 years agoconfigure: More use of AC_ARG_VAR
Peter Eisentraut [Fri, 18 Jan 2019 07:29:42 +0000 (08:29 +0100)]
configure: More use of AC_ARG_VAR

AC_ARG_VAR is necessary if an environment variable influences a
configure result that is then used by other tests that are cached.
With AC_ARG_VAR, a change in the variable is detected on subsequent
configure runs and the user is then advised to remove the cache.

This adds AC_ARG_VAR calls for: MSGFMT, PERL, PYTHON, TCLSH, XML2_CONFIG

Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://www.postgresql.org/message-id/30672.1546816567@sss.pgh.pa.us

5 years agoFix incorrect relation name in comment of vacuumlazy.c
Michael Paquier [Fri, 18 Jan 2019 04:53:43 +0000 (13:53 +0900)]
Fix incorrect relation name in comment of vacuumlazy.c

Author: Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoBiOiapB7YGbWRfNZji3cs1gkEwv=uGLTemaZ9yNKK1DA@mail.gmail.com

5 years agoEnforce non-parallel plan when calling current_schema() in newly-added test
Michael Paquier [Fri, 18 Jan 2019 01:51:39 +0000 (10:51 +0900)]
Enforce non-parallel plan when calling current_schema() in newly-added test

current_schema() gets called in the recently-added regression test from
c5660e0, and can be used in a parallel context, causing its call to fail
when creating a temporary schema.

Per buildfarm members crake and lapwing.

Discussion: https://postgr.es/m/20190118005949.GD1883@paquier.xyz

5 years agoAvoid assuming that we know the spelling of getopt_long's error messages.
Tom Lane [Fri, 18 Jan 2019 00:31:03 +0000 (19:31 -0500)]
Avoid assuming that we know the spelling of getopt_long's error messages.

I've had enough of "fixing" this test case.  Whatever value it has
is limited to verifying that pgbench fails for an unrecognized switch,
and we don't need to assume anything about what getopt_long prints in
order to do that.

Discussion: https://postgr.es/m/9427.1547701450@sss.pgh.pa.us

5 years agoRestrict the use of temporary namespace in two-phase transactions
Michael Paquier [Fri, 18 Jan 2019 00:21:44 +0000 (09:21 +0900)]
Restrict the use of temporary namespace in two-phase transactions

Attempting to use a temporary table within a two-phase transaction is
forbidden for ages.  However, there have been uncovered grounds for
a couple of other object types and commands which work on temporary
objects with two-phase commit.  In short, trying to create, lock or drop
an object on a temporary schema should not be authorized within a
two-phase transaction, as it would cause its state to create
dependencies with other sessions, causing all sorts of side effects with
the existing session or other sessions spawned later on trying to use
the same temporary schema name.

Regression tests are added to cover all the grounds found, the original
report mentioned function creation, but monitoring closer there are many
other patterns with LOCK, DROP or CREATE EXTENSION which are involved.
One of the symptoms resulting in combining both is that the session
which used the temporary schema is not able to shut down completely,
waiting for being able to drop the temporary schema, something that it
cannot complete because of the two-phase transaction involved with
temporary objects.  In this case the client is able to disconnect but
the session remains alive on the backend-side, potentially blocking
connection backend slots from being used.  Other problems reported could
also involve server crashes.

This is back-patched down to v10, which is where 9b013dc has introduced
MyXactFlags, something that this patch relies on.

Reported-by: Alexey Bashtanov
Author: Michael Paquier
Reviewed-by: Masahiko Sawada
Discussion: https://postgr.es/m/5d910e2e-0db8-ec06-dd5f-baec420513c3@imap.cc
Backpatch-through: 10

5 years agoReplace references to mailinglists with @lists.postgresql.org
Magnus Hagander [Thu, 17 Jan 2019 12:42:40 +0000 (13:42 +0100)]
Replace references to mailinglists with @lists.postgresql.org

The namespace for all lists have changed a while ago, so all references
should use the correct address.

5 years agoRemove references to Majordomo
Magnus Hagander [Thu, 17 Jan 2019 12:35:34 +0000 (13:35 +0100)]
Remove references to Majordomo

Lists are not handled by Majordomo anymore and haven't been for a while,
so remove the reference and instead direct people to the list server.

5 years agoPostpone aggregate checks until after collation is assigned.
Andrew Gierth [Thu, 17 Jan 2019 05:33:01 +0000 (05:33 +0000)]
Postpone aggregate checks until after collation is assigned.

Previously, parseCheckAggregates was run before
assign_query_collations, but this causes problems if any expression
has already had a collation assigned by some transform function (e.g.
transformCaseExpr) before parseCheckAggregates runs. The differing
collations would cause expressions not to be recognized as equal to
the ones in the GROUP BY clause, leading to spurious errors about
unaggregated column references.

The result was that CASE expr WHEN val ... would fail when "expr"
contained a GROUPING() expression or matched one of the group by
expressions, and where collatable types were involved; whereas the
supposedly identical CASE WHEN expr = val ... would succeed.

Backpatch all the way; this appears to have been wrong ever since
collations were introduced.

Per report from Guillaume Lelarge, analysis and patch by me.

Discussion: https://postgr.es/m/CAECtzeVSO_US8C2Khgfv54ZMUOBR4sWq+6_bLrETnWExHT=rFg@mail.gmail.com
Discussion: https://postgr.es/m/87muo0k0c7.fsf@news-spur.riddles.org.uk

5 years agoDoc: enhance pgbench manual.
Tatsuo Ishii [Thu, 17 Jan 2019 06:34:41 +0000 (15:34 +0900)]
Doc: enhance pgbench manual.

Clarify the difference between "prepared mode" and other query modes.

Discussion: https://postgr.es/m/20181030.103654.2249812451112831300.t-ishii@sraoss.co.jp
Reviewed by: Fabien Coelh and Alvaro Herrera.

5 years agopostgres_fdw: Remove duplicate code in DML execution callback functions.
Etsuro Fujita [Thu, 17 Jan 2019 05:37:33 +0000 (14:37 +0900)]
postgres_fdw: Remove duplicate code in DML execution callback functions.

postgresExecForeignInsert(), postgresExecForeignUpdate(), and
postgresExecForeignDelete() are coded almost identically, except that
postgresExecForeignInsert() does not need CTID.  Extract that code into
a separate function and use it in all the three function implementations.

Author: Ashutosh Bapat
Reviewed-By: Michael Paquier
Discussion: https://postgr.es/m/CAFjFpRcz8yoY7cBTYofcrCLwjaDeCcGKyTUivUbRiA57y3v-bw%40mail.gmail.com

5 years agoReorganize planner code moved in b60c39759908
Alvaro Herrera [Wed, 16 Jan 2019 19:27:44 +0000 (16:27 -0300)]
Reorganize planner code moved in b60c39759908

It seems modules are better defined like this instead of the original
split.

Per complaints from David Rowley as well as Amit Langote's self review.
Discussion: https://postgr.es/m/CAKJS1f988rsyhwvLgfT-y1UCYUfXDOv67ENQk=v24OxhsZOzZw@mail.gmail.com

5 years agoIncrease test coverage in RI_Initial_Check()
Peter Eisentraut [Wed, 16 Jan 2019 15:53:55 +0000 (16:53 +0100)]
Increase test coverage in RI_Initial_Check()

This covers the special error handling of FKCONSTR_MATCH_FULL.

Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>
Reviewed-by: Mi Tar <mmitar@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/7ae17c95-0c99-d420-032a-c271f510112b@2ndquadrant.com/

5 years agoIncrease test coverage in RI_FKey_fk_upd_check_required()
Peter Eisentraut [Wed, 16 Jan 2019 15:53:47 +0000 (16:53 +0100)]
Increase test coverage in RI_FKey_fk_upd_check_required()

This checks the code path of FKCONSTR_MATCH_FULL and
RI_KEYS_SOME_NULL.

Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>
Reviewed-by: Mi Tar <mmitar@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/7ae17c95-0c99-d420-032a-c271f510112b@2ndquadrant.com/

5 years agoIncrease test coverage in RI_FKey_pk_upd_check_required()
Peter Eisentraut [Wed, 16 Jan 2019 15:53:38 +0000 (16:53 +0100)]
Increase test coverage in RI_FKey_pk_upd_check_required()

This checks the case where the primary key has at least one null
column.

Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>
Reviewed-by: Mi Tar <mmitar@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/7ae17c95-0c99-d420-032a-c271f510112b@2ndquadrant.com/

5 years agoAdd test case for ON DELETE NO ACTION/RESTRICT
Peter Eisentraut [Wed, 16 Jan 2019 15:52:07 +0000 (16:52 +0100)]
Add test case for ON DELETE NO ACTION/RESTRICT

This was previously not covered at all; function
RI_FKey_restrict_del() was not exercised in the tests.

Reviewed-by: Alvaro Herrera <alvherre@2ndquadrant.com>
Reviewed-by: Mi Tar <mmitar@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/7ae17c95-0c99-d420-032a-c271f510112b@2ndquadrant.com/

5 years agoDon't duplicate parallel seqscan shmem sizing logic in nbtree.
Andres Freund [Tue, 15 Jan 2019 20:19:21 +0000 (12:19 -0800)]
Don't duplicate parallel seqscan shmem sizing logic in nbtree.

This is architecturally mildly problematic, which becomes more
pronounced with the upcoming introduction of pluggable storage.

To fix, teach heap_parallelscan_estimate() to deal with SnapshotAny
snapshots, and then use it from _bt_parallel_estimate_shared().

Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de

5 years agoMove vacuumlazy.c into access/heap.
Andres Freund [Tue, 15 Jan 2019 20:06:19 +0000 (12:06 -0800)]
Move vacuumlazy.c into access/heap.

It's heap table storage specific code that can't realistically be
generalized into table AM agnostic code.

Author: Andres Freund
Discussion: https://postgr.es/m/20180703070645.wchpu5muyto5n647@alap3.anarazel.de

5 years agoFix parent of WCO qual.
Andres Freund [Tue, 15 Jan 2019 19:59:32 +0000 (11:59 -0800)]
Fix parent of WCO qual.

The parent of some WCO expressions was, apparently by accident, set to
the the source of DML queries, rather than the target table.  This
causes problems for the upcoming pluggable storage work, because the
target and source table might be of different storage types.

It's possible that this is already problematic, but neither
experimenting nor inquiries on -hackers have found them. So don't
backpatch for now.

Author: Andres Freund
Discussion: https://postgr.es/m/20181205225213.hiwa3kgoxeybqcqv@alap3.anarazel.de

5 years agoFinish reverting "recheck_on_update" patch.
Tom Lane [Tue, 15 Jan 2019 17:07:10 +0000 (12:07 -0500)]
Finish reverting "recheck_on_update" patch.

This reverts commit c203d6cf8 and some follow-on fixes, completing the
task begun in commit 5d28c9bd7.  If that feature is ever resurrected,
the code will look quite a bit different from this, so it seems best
to start from a clean slate.

The v11 branch is not touched; in that branch, the recheck_on_update
storage option remains present, but nonfunctional and undocumented.

Discussion: https://postgr.es/m/20190114223409.3tcvejfhlvbucrv5@alap3.anarazel.de

5 years agoDon't include genam.h from execnodes.h and relscan.h anymore.
Andres Freund [Tue, 15 Jan 2019 01:02:12 +0000 (17:02 -0800)]
Don't include genam.h from execnodes.h and relscan.h anymore.

This is the genam.h equivalent of 4c850ecec649c (which removed
heapam.h from a lot of other headers).  There's still a few header
includes of genam.h, but not from central headers anymore.

As a few headers are not indirectly included anymore, execnodes.h and
relscan.h need a few additional includes. Some of the depended on
types were replacable by using the underlying structs, but e.g. for
Snapshot in execnodes.h that'd have gotten more invasive than
reasonable in this commit.

Like the aforementioned commit 4c850ecec649c, this requires adding new
genam.h includes to a number of backend files, which likely is also
required in a few external projects.

Author: Andres Freund
Discussion: https://postgr.es/m/20190114000701.y4ttcb74jpskkcfb@alap3.anarazel.de

5 years agoMake naming of tupdesc related structs more consistent with the rest of PG.
Andres Freund [Tue, 15 Jan 2019 00:15:20 +0000 (16:15 -0800)]
Make naming of tupdesc related structs more consistent with the rest of PG.

We usually don't change the name of structs between the struct name
itself and the name of the typedef. Additionally, structs that are
usually used via a typedef that hides being a pointer, are commonly
suffixed Data.  Change tupdesc code to follow those convention.

This is triggered by a future patch that intends to forward declare
TupleDescData in another header - keeping with the naming scheme makes
that easier to understand.

Author: Andres Freund
Discussion: https://postgr.es/m/20190114000701.y4ttcb74jpskkcfb@alap3.anarazel.de

5 years agoRemove too generically named MissingPtr typedef.
Andres Freund [Tue, 15 Jan 2019 00:07:22 +0000 (16:07 -0800)]
Remove too generically named MissingPtr typedef.

As there's only a single user of the typedef in the entire codebase,
just use the underlying struct directly.

Per complaint from Alvaro Herrera

Author: Andres Freund
Discussion: https://postgr.es/m/201901141836.oxtm4uzc63j3@alvherre.pgsql

5 years agoDon't include heapam.h from others headers.
Andres Freund [Mon, 14 Jan 2019 23:54:18 +0000 (15:54 -0800)]
Don't include heapam.h from others headers.

heapam.h previously was included in a number of widely used
headers (e.g. execnodes.h, indirectly in executor.h, ...). That's
problematic on its own, as heapam.h contains a lot of low-level
details that don't need to be exposed that widely, but becomes more
problematic with the upcoming introduction of pluggable table storage
- it seems inappropriate for heapam.h to be included that widely
afterwards.

heapam.h was largely only included in other headers to get the
HeapScanDesc typedef (which was defined in heapam.h, even though
HeapScanDescData is defined in relscan.h). The better solution here
seems to be to just use the underlying struct (forward declared where
necessary). Similar for BulkInsertState.

Another problem was that LockTupleMode was used in executor.h - parts
of the file tried to cope without heapam.h, but due to the fact that
it indirectly included it, several subsequent violations of that goal
were not not noticed. We could just reuse the approach of declaring
parameters as int, but it seems nicer to move LockTupleMode to
lockoptions.h - that's not a perfect location, but also doesn't seem
bad.

As a number of files relied on implicitly included heapam.h, a
significant number of files grew an explicit include. It's quite
probably that a few external projects will need to do the same.

Author: Andres Freund
Reviewed-By: Alvaro Herrera
Discussion: https://postgr.es/m/20190114000701.y4ttcb74jpskkcfb@alap3.anarazel.de

5 years agoFix typos in documentation and for one wait event
Michael Paquier [Mon, 14 Jan 2019 23:47:01 +0000 (08:47 +0900)]
Fix typos in documentation and for one wait event

These have been found while cross-checking for the use of unique words
in the documentation, and a wait event was not getting generated in a way
consistent to what the documentation provided.

Author: Alexander Lakhin
Discussion: https://postgr.es/m/9b5a3a85-899a-ae62-dbab-1e7943aa5ab1@gmail.com

5 years agoRe-add default_with_oids GUC to avoid breaking old dump files.
Andres Freund [Mon, 14 Jan 2019 23:30:24 +0000 (15:30 -0800)]
Re-add default_with_oids GUC to avoid breaking old dump files.

After 578b229718 / the removal of WITH OIDS support, older dump files
containing
    SET default_with_oids = false;
either report unnecessary errors (as the subsequent tables have no
oids) or even fail to restore entirely (when using transaction mode).
To avoid that, re-add the GUC, but don't allow setting it to true.

Per complaint from Tom Lane.

Author: Amit Khandekar, editorialized by me
Discussion: https://postgr.es/m/CAJ3gD9dZyxrtL0rJfoNoOj6v7fJSDaXBngi9wy5XU8m-ioXhAA@mail.gmail.com

5 years agoFix unique INCLUDE indexes on partitioned tables
Alvaro Herrera [Mon, 14 Jan 2019 22:25:19 +0000 (19:25 -0300)]
Fix unique INCLUDE indexes on partitioned tables

We were considering the INCLUDE columns as part of the key, allowing
unicity-violating rows to be inserted in different partitions.

Concurrent development conflict in eb7ed3f30634 and 8224de4f42cc.

Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190109065109.GA4285@telsasoft.com