Rethink heuristics for choosing index quals for parameterized paths.

Some experimentation with examples similar to bug #7539 has convinced me
that indxpath.c's original implementation of parameterized-path generation
was several bricks shy of a load.  In general, if we are relying on a
particular outer rel or set of outer rels for a parameterized path, the
path should use every indexable join clause that's available from that rel
or rels.  Any join clauses that get left out of the indexqual will end up
getting applied as plain filter quals (qpquals), and that's generally a
significant loser compared to having the index AM enforce them.  (This is
particularly true with btree, which can skip the index scan entirely if
it can see that the given indexquals are mutually contradictory.)  The
original heuristics failed to ensure this, though, and were overly
complicated anyway.  Rewrite to make the code explicitly identify each
useful set of outer rels and then select all applicable join clauses for
each one.  The one plan that changes in the regression tests is in fact
for the better according to the planner's cost estimates.

(Note: this is not a correctness issue but just a matter of plan quality.
I don't yet know what is going on in bug #7539, but I don't expect this
change to fix that.)

Fix bufmgr so CHECKPOINT_END_OF_RECOVERY behaves as a shutdown checkpoint.
Recovery code documents clearly that a shutdown checkpoint is executed at
end of recovery - a shutdown checkpoint WAL record is written but the buffer
manager had been altered to treat end of recovery as a normal checkpoint.
This bug exacerbates the bufmgr relpersistence bug.

Bug spotted by Andres Freund, patch by me.

Fix documentation reference to maximum allowed for autovacuum_freeze_max_age.

The documentation mentioned setting autovacuum_freeze_max_age to
"its maximum allowed value of a little less than two billion".
This led to a post asking about the exact maximum allowed value,
which is precisely two billion, not "a little less".

Based on question by Radovan Jablonovsky.  Backpatch to 8.3.

Adjust largeobject_1.source per buildfarm.

Looks like the correct size of DOS-ified tenk.data is 680800 not 680801.
(I got the latter from a version of unix2dos that appends a trailing ^Z,
which evidently is not git's practice.)

psql: Add more constraint completion

- ALTER DOMAIN ... DROP/RENAME/VALIDATE CONSTRAINT
- ALTER TABLE ... RENAME/VALIDATE CONSTRAINT
- COMMENT ON CONSTRAINT
- SET CONSTRAINTS

Improve largeobject regression test to show size of object read from file.

The idea here is to provide a more easily diagnosable failure diff when
the problem is that tenk.data has been DOS-ified, as I believe to be
happening currently on buildfarm member hamerkop.  Per suggestion from
Magnus Hagander.

Also, sync output/largeobject_1.source with current regression test.
Failure to do that in commit 3a0e4d36ebd7f477822d5bae41ba121a40d22ccc
turns out to be the real reason that hamerkop has been complaining.

Add a regression test case based on bug #7516.

Given what we now know about the cause of this bug, it seems like it'd
be a real good idea to include it in the plperl regression tests, so as
to catch any platform-specific cases where the code gets misoptimized.

Properly set relpersistence for fake relcache entries.

This can result in buffers failing to be properly flushed at
checkpoint time, leading to data loss.

Report, diagnosis, and patch by Jeff Davis.

Keep plperl's current_call_data record on the stack, instead of palloc'ing.

This at least saves some palloc overhead, and should furthermore reduce
the risk of anything going wrong, eg somebody resetting the context the
current_call_data record was in.

Fix case of window function + aggregate + GROUP BY expression.

In commit 1bc16a946008a7cbb33a9a06a7c6765a807d7f59 I added a minor
optimization to drop the component variables of a GROUP BY expression from
the target list computed at the aggregation level of a query, if those Vars
weren't referenced elsewhere in the tlist.  However, I overlooked that the
window-function planning code would deconstruct such expressions and thus
need to have access to their component variables.  Fix it to not do that.

While at it, I removed the distinction between volatile and nonvolatile
window partition/order expressions: the code now computes all of them
at the aggregation level.  This saves a relatively expensive check for
volatility, and it's unclear that the resulting plan isn't better anyway.

Per bug #7535 from Louis-David Mitterrand.  Back-patch to 9.2.

Fix typo in comment for pclose_check() function.

Backpatch to 9.2.

Etsuro Fujit

Fix a couple other leftover uses of 'conisonly' terminology.

Fix catalog docs to reflect connoinherit change in 09ff76f.

Backpatch to 9.2.

Fix logical errors in tsquery selectivity estimation for prefix queries.

I made multiple errors in commit 97532f7c29468010b87e40a04f8daa3eb097f654,
stemming mostly from failure to think about the available frequency data
as being element frequencies not value frequencies (so that occurrences of
different elements are not mutually exclusive).  This led to sillinesses
such as estimating that "word" would match more rows than "word:*".

The choice to clamp to a minimum estimate of DEFAULT_TS_MATCH_SEL also
seems pretty ill-considered in hindsight, as it would frequently result in
an estimate much larger than the available data suggests.  We do need some
sort of clamp, since a pattern not matching any of the MCELEMs probably
still needs a selectivity estimate of more than zero.  I chose instead to
clamp to at least what a non-MCELEM word would be estimated as, preserving
the property that "word:*" doesn't get an estimate less than plain "word",
whether or not the word appears in MCELEM.

Per investigation of a gripe from Bill Martin, though I suspect that his
example case actually isn't even reaching the erroneous code.

Back-patch to 9.1 where this code was introduced.

Fix typo: lexemes misspelled in full text search docs.

Dan Scott

Add vcregress.pl target for checking pg_upgrade.

This follows recent addition of Windows/Mingw testing.
Backpatch to Release 9.2 so we can get some buildfarm testing
going.

Make plperl safe against functions that are redefined while running.

validate_plperl_function() supposed that it could free an old
plperl_proc_desc struct immediately upon detecting that it was stale.
However, if a plperl function is called recursively, this could result
in deleting the struct out from under an outer invocation, leading to
misbehavior or crashes.  Add a simple reference-count mechanism to
ensure that such structs are freed only when the last reference goes
away.

Per investigation of bug #7516 from Marko Tiikkaja.  I am not certain
that this error explains his report, because he says he didn't have
any recursive calls --- but it's hard to see how else it could have
crashed right there.  In any case, this definitely fixes some problems
in the area.

Back-patch to all active branches.

Use .NOTPARALLEL in ecpg/Makefile to avoid a gmake parallelism bug.

Investigation shows that some intermittent build failures in ecpg are the
result of a gmake bug that was reported quite some time ago:
http://savannah.gnu.org/bugs/?30653

Preventing parallel builds of the ecpg subdirectories seems to dodge the
bug.  Per yesterday's pgsql-hackers discussion, there are some other things
in the subdirectory makefiles that seem rather unsafe for parallel builds
too, but there's little point in fixing them as long as we have to work
around a make bug.

Back-patch to 9.1; parallel builds weren't very well supported before
that anyway.

Adjust PL/Python regression tests some more for Python 3.3.

Commit 2cfb1c6f77734db81b6e74bcae630f93b94f69be fixed some issues caused
by Python 3.3 choosing to iterate through dict entries in a different order
than before.  But here's another one: the test cases adjusted here made two
bad entries in a dict and expected the one complained of would always be
the same.

Possibly this should be back-patched further than 9.2, but there seems
little point unless the earlier fix is too.

Centralize libpq's low-level code for dropping a connection.

Create an internal function pqDropConnection that does the physical socket
close and cleans up closely-associated state.  This removes a bunch of ad
hoc, not always consistent closure code.  The ulterior motive is to have a
single place to wait for a spawned child backend to exit, but this seems
like good cleanup even if that never happens.

I went back and forth on whether to include "conn->status = CONNECTION_BAD"
in pqDropConnection's actions, but for the moment decided not to.  Only a
minority of the call sites actually want that, and in any case it's
arguable that conn->status is slightly higher-level state, and thus not
part of this function's purview.

Update syntax shown for \copy to match new syntax for COPY.

Etsuro Fujita

Fix "too many arguments" messages not to index off the end of argv[].

This affects initdb, clusterdb, reindexdb, and vacuumdb in master
and 9.2; in earlier branches, only initdb is affected.

Allow embedded spaces without quoting in unix_socket_directories entries.

This fix removes an unnecessary incompatibility with the old behavior of
the unix_socket_directory parameter.  Since pathnames with embedded spaces
are fairly popular on some platforms, the incompatibility could be
significant in practice.  We'll still strip unquoted leading/trailing
spaces, however.

No docs update since the documentation already implied that it worked
like this.

Per bug #7514 from Murray Cumming.

Fix typo in information_schema documentation.

Shigeru Hanada

In pg_upgrade, try a few times to open a log file.

If we call pg_ctl stop, the server might continue and thus
hold a log file for a short time after it has deleted its pid file,
(which is when pg_ctl will exit), and so a subsequent attempt to
open the log file might fail.

We therefore try to open it a few times, sleeping one second between
tries, to give the server time to exit.

This corrects an error that was observed on the buildfarm.

Backpatched to 9.2,

pgbench: Show better progress when loading tuples

Show target number of tuples and percentage in addition to current
number.

Fix WAL file replacement during cascading replication on Windows.

When the startup process restores a WAL file from the archive, it deletes
any old file with the same name and renames the new file in its place. On
Windows, however, when a file is deleted, it still lingers as long as a
process holds a file handle open on it. With cascading replication, a
walsender process can hold the old file open, so the rename() in the startup
process would fail. To fix that, rename the old file to a temporary name, to
make the original file name available for reuse, before deleting the old
file.

Fix inappropriate error messages for Hot Standby misconfiguration errors.

Give the correct name of the GUC parameter being complained of.
Also, emit a more suitable SQLSTATE (INVALID_PARAMETER_VALUE,
not the default INTERNAL_ERROR).

Gurjeet Singh, errcode adjustment by me

Make one last copy-editing pass over the 9.2 release notes.

Also, set the release date to 2012-09-10, since we're pretty well
committed to that now.

Fix pg_upgrade test script's line end handling on Windows.

Call pg_dumpall using -f switch instead of redirection, to avoid
writing the output in text mode and generating spurious carriage
returns. Remove to carriage return ignoring hack introduced by
commit e442b0f0c6fd26738bafdeb5222511b586dfe4b9.

Backpatch to 9.2.

Fix line end mishandling in pg_upgrade on Windows.

pg_upgrade opened the output from pg_dumpall in text mode and
wrote the split files in text mode. This caused unwanted eating
of intended carriage returns on input and production of spurious
carriage returns on output. To avoid this, open all these files
in binary mode. On non-Windows platforms, this change has no
effect.

Backpatch to 9.0. On 9.0 and 9.1, we also switch from redirecting
pg_dumpall's output to using pg_dumpall's -f switch, for the same
reason.

Restore SIGFPE handler after initializing PL/Perl.

Perl, for some unaccountable reason, believes it's a good idea to reset
SIGFPE handling to SIG_IGN.  Which wouldn't be a good idea even if it
worked; but on some platforms (Linux at least) it doesn't work at all,
instead resulting in forced process termination if the signal occurs.
Given the lack of other complaints, it seems safe to assume that Perl
never actually provokes SIGFPE and so there is no value in the setting
anyway.  Hence, reset it to our normal handler after initializing Perl.

Report, analysis and patch by Andres Freund.

Silence -Wunused-result warning in contrib/pg_upgrade.

This is just neatnik-ism, but since we do it for comparable code in elog.c,
we may as well do it here.

sepgsql cleanups.

This is needed to match recent changes elsewhere.  Along the way, some
renaming for clarity.

KaiGai Kohei

Fix PARAM_EXEC assignment mechanism to be safe in the presence of WITH.

The planner previously assumed that parameter Vars having the same absolute
query level, varno, and varattno could safely be assigned the same runtime
PARAM_EXEC slot, even though they might be different Vars appearing in
different subqueries.  This was (probably) safe before the introduction of
CTEs, but the lazy-evalution mechanism used for CTEs means that a CTE can
be executed during execution of some other subquery, causing the lifespan
of Params at the same syntactic nesting level as the CTE to overlap with
use of the same slots inside the CTE.  In 9.1 we created additional hazards
by using the same parameter-assignment technology for nestloop inner scan
parameters, but it was broken before that, as illustrated by the added
regression test.

To fix, restructure the planner's management of PlannerParamItems so that
items having different semantic lifespans are kept rigorously separated.
This will probably result in complex queries using more runtime PARAM_EXEC
slots than before, but the slots are cheap enough that this hardly matters.
Also, stop generating PlannerParamItems containing Params for subquery
outputs: all we really need to do is reserve the PARAM_EXEC slot number,
and that now only takes incrementing a counter.  The planning code is
simpler and probably faster than before, as well as being more correct.

Per report from Vik Reykja.

These changes will mostly also need to be made in the back branches, but
I'm going to hold off on that until after 9.2.0 wraps.

Trim spgist_private.h inclusion

It doesn't really need rel.h; relcache.h is enough.

Fix compiler warnings about unused variables, caused by my previous commit.

Reported by Peter Eisentraut.

In pg_upgrade, document why we can't issue \n\n in the command logfile
on Windows.  Slightly cleanup log output on Windows given this
restriction.

Backpatch to 9.2.

Fix bugs in cascading replication with recovery_target_timeline='latest'

The cascading replication code assumed that the current RecoveryTargetTLI
never changes, but that's not true with recovery_target_timeline='latest'.
The obvious upshot of that is that RecoveryTargetTLI in shared memory needs
to be protected by a lock. A less obvious consequence is that when a
cascading standby is connected, and the standby switches to a new target
timeline after scanning the archive, it will continue to stream WAL to the
cascading standby, but from a wrong file, ie. the file of the previous
timeline. For example, if the standby is currently streaming from the middle
of file 000000010000000000000005, and the timeline changes, the standby
will continue to stream from that file. However, the WAL on the new
timeline is in file 000000020000000000000005, so the standby sends garbage
from 000000010000000000000005 to the cascading standby, instead of the
correct WAL from file 000000020000000000000005.

This also fixes a related bug where a partial WAL segment is restored from
the archive and streamed to a cascading standby. The code assumed that when
a WAL segment is copied from the archive, it can immediately be fully
streamed to a cascading standby. However, if the segment is only partially
filled, ie. has the right size, but only N first bytes contain valid WAL,
that's not safe. That can happen if a partial WAL segment is manually copied
to the archive, or if a partial WAL segment is archived because a server is
started up on a new timeline within that segment. The cascading standby will
get confused if the WAL it received is not valid, and will get stuck until
it's restarted. This patch fixes that problem by not allowing WAL restored
from the archive to be streamed to a cascading standby until it's been
replayed, and thus validated.

Fix serializable mode with index-only scans.

Serializable Snapshot Isolation used for serializable transactions
depends on acquiring SIRead locks on all heap relation tuples which
are used to generate the query result, so that a later delete or
update of any of the tuples can flag a read-write conflict between
transactions.  This is normally handled in heapam.c, with tuple level
locking.  Since an index-only scan avoids heap access in many cases,
building the result from the index tuple, the necessary predicate
locks were not being acquired for all tuples in an index-only scan.

To prevent problems with tuple IDs which are vacuumed and re-used
while the transaction still matters, the xmin of the tuple is part of
the tag for the tuple lock.  Since xmin is not available to the
index-only scan for result rows generated from the index tuples, it
is not possible to acquire a tuple-level predicate lock in such
cases, in spite of having the tid.  If we went to the heap to get the
xmin value, it would no longer be an index-only scan.  Rather than
prohibit index-only scans under serializable transaction isolation,
we acquire an SIRead lock on the page containing the tuple, when it
was not necessary to visit the heap for other reasons.

Backpatch to 9.2.

Kevin Grittner and Tom Lane

Allow isolation tests to specify multiple setup blocks.

Each setup block is run as a single PQexec submission, and some
statements such as VACUUM cannot be combined with others in such a
block.

Backpatch to 9.2.

Kevin Grittner and Tom Lane

Remove src/tool/backend, now that the content is on the web site and wiki.

Fix transcription error.

Document that pg_upgrade requires PGHOST be set for any pre-9.1 servers
with a socket directory mismatch with the new server.

Backpatch to 9.2.

Change "restoring" to "processing" in message from pg_dump

The same message is used in both pg_restore and pg_dump, and it's
confusing to output "restoring data for table xyz" when the user
is just doing a pg_dump.

Mention basebackup-from-slave next to cascading replication

Fix command echoing in pg_upgade's analyze script for Windows.

Remove some useless trailing whitespace

Michael Paquier

Indent fix_path_separator() header properly.

Fix to_date() and to_timestamp() to allow specification of the day of
the week via ISO or Gregorian designations.  The fix is to store the
day-of-week consistently as 1-7, Sunday = 1.

Fixes bug reported by Marc Munro

Allow pg_upgrade "make check" to run on Windows/MSys.

Backpatch to 9.2.

In pg_upgrade, pull the port number from postmaster.pid, like we do for
socket location.  Also, prevent putting the socket in the current
directory for pre-9.1 servers in live check and non-live check mode,
because pre-9.1 pg_ctl -w can't handle it.

Backpatch to 9.2.

Use correct path separator for Windows builtin commands.

pg_upgrade produces a platform-specific script to remove the old
directory, but on Windows it has not been making sure that the
paths it writes as arguments for rmdir and del use the backslash
path separator, which will cause these scripts to fail.

The fix is backpatched to Release 9.0.

Replace memcpy() calls in xlog.c critical sections with struct assignments.

This gets rid of a dangerous-looking use of the not-volatile XLogCtl
pointer in a couple of spinlock-protected sections, where the normal
coding rule is that you should only access shared memory through a
pointer-to-volatile.  I think the risk is only hypothetical not actual,
since for there to be a bug the compiler would have to move the spinlock
acquire or release across the memcpy() call, which one sincerely hopes
it will not.  Still, it looks cleaner this way.

Per comment from Daniel Farina and subsequent discussion.

Fix bugs in exec.c that prevented pg_upgrade working in Windows.

Backpatch to 9.2 - code before that is quite different and should
not have these defects.

Fix pg_upgrade to cope with non-default unix_socket_directory scenarios.

When starting either an old or new postmaster, force it to place its Unix
socket in the current directory.  This makes it even harder for accidental
connections to occur during pg_upgrade, and also works around some
scenarios where the default socket location isn't usable.  (For example,
if the default location is something other than "/tmp", it might not exist
during "make check".)

When checking an already-running old postmaster, find out its actual socket
directory location from postmaster.pid, if possible.  This dodges problems
with an old postmaster having a configured location different from the
default built into pg_upgrade's libpq.  We can't find that out if the old
postmaster is pre-9.1, so also document how to cope with such scenarios
manually.

In support of this, centralize handling of the connection-related command
line options passed to pg_upgrade's subsidiary programs, such as pg_dump.
This should make future changes easier.

Bruce Momjian and Tom Lane

Make psql's \d+ show reloptions for all relkinds.

Formerly it would only show them for relkinds 'r' and 'f' (plain tables
and foreign tables).  However, as of 9.2, views can also have reloptions,
namely security_barrier.  The relkind restriction seems pointless and
not at all future-proof, so just print reloptions whenever there are any.

In passing, make some cosmetic improvements to the code that pulls the
"tableinfo" fields out of the PGresult.

Noted and patched by Dean Rasheed, with adjustment for all relkinds by me.

Update URLs that pointed to sun.com;  either repoint them or remove
them.

Add small doc mention that libpq is named after POSTQUEL.

Drop cheap-startup-cost paths during add_path() if we don't need them.

We can detect whether the planner top level is going to care at all about
cheap startup cost (it will only do so if query_planner's tuple_fraction
argument is greater than zero).  If it isn't, we might as well discard
paths immediately whose only advantage over others is cheap startup cost.
This turns out to get rid of quite a lot of paths in complex queries ---
I saw planner runtime reduction of more than a third on one large query.

Since add_path isn't currently passed the PlannerInfo "root", the easiest
way to tell it whether to do this was to add a bool flag to RelOptInfo.
That's a bit redundant, since all relations in a given query level will
have the same setting.  But in the future it's possible that we'd refine
the control decision to work on a per-relation basis, so this seems like
a good arrangement anyway.

Per my suggestion of a few months ago.

Fix mark_placeholder_maybe_needed to handle LATERAL references.

If a PlaceHolderVar contains a pulled-up LATERAL reference, its minimum
possible evaluation level might be higher in the join tree than its
original syntactic location.  That in turn affects the ph_needed level for
any contained PlaceHolderVars (that is, those PHVs had better propagate up
the join tree at least to the evaluation level of the outer PHV).  We got
this mostly right, but mark_placeholder_maybe_needed() failed to account
for the effect, and in consequence could leave the inner PHVs with
ph_may_need less than what their ultimate ph_needed value will be.  That's
bad because it could lead to failure to select a join order that will allow
evaluation of the inner PHV at a valid location.  Fix that, and add an
Assert that checks that we don't ever set ph_needed to more than
ph_may_need.

Revert doc patch 305557984dd964ac397c6752e9d0f14646b60f15 as the values
are sometimes signed, sometimes unsigned.

Fix broken link in installation.sgml.

Linking to other parts of the manual doesn't work when building the
standalone INSTALL document.

Cross-link to doc build requirements from install requirements.

Jeff Janes

More documentation updates for LATERAL.

Extend xfunc.sgml's discussion of set-returning functions to show an
example of using LATERAL, and recommend that over putting SRFs in the
targetlist.

In passing, reword func.sgml's section on set-returning functions so
that it doesn't claim that the functions listed therein are all the
built-in set-returning functions.  That hasn't been true for a long
time, and trying to make it so doesn't seem like it would be an
improvement.  (Perhaps we should rename that section?)

Both per suggestions from Merlin Moncure.

psql: Reduce compatibility warning

Only warn when connecting to a newer server, since connecting to older
servers works pretty well nowadays.  Also update the documentation a
little about current psql/server compatibility expectations.

Restore setting of _USE_32BIT_TIME_T to 32 bit MSVC builds.

This was removed in commit cd004067742ee16ee63e55abfb4acbd5f09fbaab,
we're not quite sure why, but there have been reports of crashes due
to AS Perl being built with it when we are not, and it certainly
seems like the right thing to do. There is still some uncertainty
as to why it sometimes fails and sometimes doesn't.

Original patch from Owais Khani, substantially reworked and
extended by Andrew Dunstan.

Partially restore qual scope checks in distribute_qual_to_rels().

The LATERAL implementation is now basically complete, and I still don't
see a cost-effective way to make an exact qual scope cross-check in the
presence of LATERAL.  However, I did add a PlannerInfo.hasLateralRTEs flag
along the way, so it's easy to make the check only when not hasLateralRTEs.
That seems to still be useful, and it beats having no check at all.

Fix LATERAL references to join alias variables.

I had thought this case worked already, but perhaps I didn't re-test it
after adding extract_lateral_references() ...

In pg_upgade, document that the port numbers must be different when
checking an old running server.

Make configure probe for mbstowcs_l as well as wcstombs_l.

We previously supposed that any given platform would supply both or neither
of these functions, so that one configure test would be sufficient.  It now
appears that at least on AIX this is not the case ... which is likely an
AIX bug, but nonetheless we need to cope with it.  So use separate tests.
Per bug #6758; thanks to Andrew Hastie for doing the followup testing
needed to confirm what was happening.

Backpatch to 9.1, where we began using these functions.

Fix typos in README.

Improve coding of gistchoose and gistRelocateBuildBuffersOnSplit.

This is mostly cosmetic, but it does eliminate a speculative portability
issue.  The previous coding ignored the fact that sum_grow could easily
overflow (in fact, it could be summing multiple IEEE float infinities).
On a platform where that didn't guarantee to produce a positive result,
the code would misbehave.  In any case, it was less than readable.

Add Perl emacs formatting macros to src/tools/editors/emacs.samples.

Peter Eisentraut

Clarify FreeBSD instructions in pg_test_timing.

Josh Kupershmidt

Properly document that SIGTERM is OK for users to use on a postgres
session, now that pg_terminate_backend() uses it.

Josh Kupershmidt

Revert 1fbc30f1dca6624c01a9a6a9ff711a7036c68532 because the
--enable-shared is about Plyton's configure, not ours.

Remove doc mention of --enable-shared, per Tom.

Document that max_locks_per_transaction might need to be increased for
queries on parent tables, per suggestion from Josh Berkus.

Split tuple struct defs from htup.h to htup_details.h

This reduces unnecessary exposure of other headers through htup.h, which
is very widely included by many files.

I have chosen to move the function prototypes to the new file as well,
because that means htup.h no longer needs to include tupdesc.h.  In
itself this doesn't have much effect in indirect inclusion of tupdesc.h
throughout the tree, because it's also required by execnodes.h; but it's
something to explore in the future, and it seemed best to do the htup.h
change now while I'm busy with it.

Remove configure flag --disable-shared, as it is no longer used by any
port.  The last use was QNX, per Peter Eisentraut.

Fix checkpoint_timeout documentation to reflect current behavior.

Jeff Janes

Document that log_autovacuum_min_duration can be used to monitor
autovacuum activity.

Per report from Marc Mamin

Suppress creation of backwardly-indexed paths for LATERAL join clauses.

Given a query such as

SELECT * FROM foo JOIN LATERAL (SELECT foo.var1) ss(x) ON ss.x = foo.var2

the existence of the join clause "ss.x = foo.var2" encourages indxpath.c to
build a parameterized path for foo using any index available for foo.var2.
This is completely useless activity, though, since foo has got to be on the
outside not the inside of any nestloop join with ss.  It's reasonably
inexpensive to add tests that prevent creation of such paths, so let's do
that.

Document how to prevent PostgreSQL itself from exhausting memory.

The existing documentation in Linux Memory Overcommit seemed to
assume that PostgreSQL itself could never be the problem, or at
least it didn't tell you what to do about it.

Per discussion with Craig Ringer and Kevin Grittner.

Fix division by zero in the new range type histogram creation.

Report and analysis by Matthias.

Add missing period to detail message.

Per note from Peter Eisentraut.

Document that COPY OUT requires an absolute pathname.

As suggested by Etsuro Fujita, but with somewhat different wording.

Remove old documentation warnings about the use of bigint.

Fix logic bug in gistchoose and gistRelocateBuildBuffersOnSplit.

Every time the best-tuple-found-so-far changes, we need to reset all
the penalty values in which_grow[] to the penalties for the new best
tuple.  The old code failed to do this, resulting in inferior index
quality.

The original patch from Alexander Korotkov was just two lines; I took
the liberty of fleshing that out by adding a bunch of comments that I
hope will make this logic easier for others to understand than it was
for me.

Improve EXPLAIN's ability to cope with LATERAL references in plans.

push_child_plan/pop_child_plan didn't bother to adjust the "ancestors"
list of parent plan nodes when descending to a child plan node.  I think
this was okay when it was written, but it's not okay in the presence of
LATERAL references, since a subplan node could easily be returning a
LATERAL value back up to the same nestloop node that provides the value.
Per changed regression test results, the omission led to failure to
interpret Param nodes that have perfectly good interpretations.

Comment fixes.

Jeff Davis, somewhat edited by me

Document that xslt-related RPMs may be needed to build docs.

Also check for Python platform-specific include directory

Python can be built to have two separate include directories: one for
platform-independent files and one for platform-specific files.  So
far, this has apparently never mattered for a PL/Python build.  But
with the new multi-arch Python packages in Debian and Ubuntu, this is
becoming the standard configuration on these platforms, so we must
check these directories separately to be able to build there.

Also add a bit of reporting in configure to be able to see better what
is going on with this.

Adjust definition of cheapest_total_path to work better with LATERAL.

In the initial cut at LATERAL, I kept the rule that cheapest_total_path
was always unparameterized, which meant it had to be NULL if the relation
has no unparameterized paths.  It turns out to work much more nicely if
we always have *some* path nominated as cheapest-total for each relation.
In particular, let's still say it's the cheapest unparameterized path if
there is one; if not, take the cheapest-total-cost path among those of
the minimum available parameterization.  (The first rule is actually
a special case of the second.)

This allows reversion of some temporary lobotomizations I'd put in place.
In particular, the planner can now consider hash and merge joins for
joins below a parameter-supplying nestloop, even if there aren't any
unparameterized paths available.  This should bring planning of
LATERAL-containing queries to the same level as queries not using that
feature.

Along the way, simplify management of parameterized paths in add_path()
and friends.  In the original coding for parameterized paths in 9.2,
I tried to minimize the logic changes in add_path(), so it just treated
parameterization as yet another dimension of comparison for paths.
We later made it ignore pathkeys (sort ordering) of parameterized paths,
on the grounds that ordering isn't a useful property for the path on the
inside of a nestloop, so we might as well get rid of useless parameterized
paths as quickly as possible.  But we didn't take that reasoning as far as
we should have.  Startup cost isn't a useful property inside a nestloop
either, so add_path() ought to discount startup cost of parameterized paths
as well.  Having done that, the secondary sorting I'd implemented (in
add_parameterized_path) is no longer needed --- any parameterized path that
survives add_path() at all is worth considering at higher levels.  So this
should be a bit faster as well as simpler.

Document that NOTIFY events are visible to all users.

Report postmaster.pid file as empty if it is empty, rather than
reporting in contains invalid data.

Optimize SP-GiST insertions.

This includes two micro-optimizations to the tight inner loop in descending
the SP-GiST tree: 1. avoid an extra function call to index_getprocinfo when
calling user-defined choose function, and 2. avoid a useless palloc+pfree
when node labels are not used.

Fix assorted compilation failures in contrib

Evidently I failed to test a compile after my earlier header shuffling.

Add strerror() string to chdir() error message