On further analysis, it turns out that it is not needed to duplicate predicate
locks to the new row version at update, the lock on the version that the
transaction saw as visible is enough. However, there was a different bug in
the code that checks for dangerous structures when a new rw-conflict happens.
Fix that bug, and remove all the row-version chaining related code.

Kevin Grittner & Dan Ports, with some comment editorialization by me.

According to perlguts, &PL_sv_undef is not the right thing to use in
those cases because it doesn't behave the same way as an undef value via
Perl code.  Seems the intuitive way to deal with undef values is subtly
enough broken that it's hard to notice when misused.

The broken uses got inadvertently introduced in commit
87bb2ade by Alexey Klyukin, Alex
Hunsaker and myself on 2011-02-17; no backpatch is necessary.

Per testing report from Greg Mullane.

Author: Alex Hunsaker

The previous claim when these parameters could be changed was
incorrect.

Fujii Masao

parse_xml_decl's header comment says you can pass NULL for any unwanted
output parameter, but it failed to honor this contract for the "standalone"
flag.  The only currently-affected caller is xml_recv, so the net effect is
that sending a binary XML value containing a standalone parameter in its
xml declaration would crash the backend.  Per bug #6044 from Christopher
Dillard.

In passing, remove useless initializations of parse_xml_decl's output
parameters in xml_parse.

Back-patch to 8.3, where this code was introduced.

Cédric Villemain

This is currently the same as the condition name, so it doesn't add
any value, only clutter.

With "-w -t 0", we should report "still starting up", not "ok".  If we
fall out of the loop without ever being able to call PQping (because we
were never able to construct a connection string), report "no response",
not "ok".  This gets rid of corner cases in which we'd claim the server
had started even though it had not.

Also, if the postmaster.pid file is not there at any point after we've
waited 5 seconds, assume the postmaster has failed and report that, rather
than almost-certainly-fruitlessly continuing to wait.  The pidfile should
appear almost instantly even when there is extensive startup work to do,
so 5 seconds is already a very conservative figure.  This part is per a
gripe from MauMau --- there might be better ways to do it, but nothing
simple enough to get done for 9.1.

This is necessary to avoid long-term memory leakage, because the main loop
in PostgresMain expects to be executing in MessageContext, and hence is a
bit sloppy about freeing stuff that is only needed for the duration of
processing the current client message.  The known case of an actual leak
is when encoding conversion has to be done on the incoming command string,
but there might be others.  Per report from Per-Olov Esgard.

Back-patch to 9.0, where the bug was introduced by the LISTEN/NOTIFY
rewrite.

loop if it fails, which is what what happened on my HP-UX box. (I think
the reason it failed on that box is a misconfiguration on my behalf, but
that's no reason to hang.)

We had some hacks in ruleutils.c to cope with various odd transformations
that the optimizer could do on a CASE foo WHEN "CaseTestExpr = RHS" clause.
However, the fundamental impossibility of covering all cases was exposed
by Heikki, who pointed out that the "=" operator could get replaced by an
inlined SQL function, which could contain nearly anything at all.  So give
up on the hacks and just print the expression as-is if we fail to recognize
it as "CaseTestExpr = RHS".  (We must cover that case so that decompiled
rules print correctly; but we are not under any obligation to make EXPLAIN
output be 100% valid SQL in all cases, and already could not do so in some
other cases.)  This approach requires that we have some printable
representation of the CaseTestExpr node type; I used "CASE_TEST_EXPR".

Back-patch to all supported branches, since the problem case fails in all.

This is reported to be necessary on some versions of that OS.  In service
of this, cause PGAC_PROG_CC_CFLAGS_OPT to reject switches that result in
compiler warnings, since on yet other versions of that OS, the switch does
nothing except provoke a warning.

Report and patch by Ibrar Ahmed, further tweaking by me.

We initially had pg_dump emit CREATE EXTENSION commands unconditionally.
However, pg_dump has long been in the habit of not dumping procedural
language definitions when a --schema or --table switch is given.  It seems
appropriate to handle extensions the same way, since like PLs they are SQL
objects that are not in any particular schema.  Per complaint from Adrian
Schreyer.

For the --help output and reference pages of pg_dump, pg_dumpall,
pg_restore, put the options in some consistent, mostly alphabetical,
and consistent order, rather than newest option last or something like
that.

The old .bat file wasn't working for reasons that are unclear, and
which it did not seem worth the trouble to ascertain.
The new perl script has been tested and is known to work.
Soon it will be tested regularly on the buildfarm.
The .bat file is kept as a simple wrapper for the perl script.

Josh Kupershmidt

Clear isReset before, not after, calling the context-specific alloc method,
so as to preserve the option to do a tail call in MemoryContextAlloc
(and also so this code isn't assuming that a failed alloc call won't have
changed the context's state before failing).  Fix missed direct invocation
of reset method.  Reformat a comment.

because these are often inconsistently capitalized.

We need at least version 2.0.93, so probe for a function that was added
in that version.

Kaigai Kohei

Also adjust alignment a bit to distinguish commented out from comment.

Found with additional valgrind testing.

Noah Misch

The core CREATE FUNCTION code only enforces that IN parameter names are
non-duplicate, and that OUT parameter names are separately non-duplicate.
This is because some function languages might not have any confusion
between the two.  But in plpgsql, such names are all in the same namespace,
so we'd better disallow it.

Per a recent complaint from Dan S.  Not back-patching since this is a small
issue and the change could cause unexpected failures if we started to
enforce it in a minor release.

In the passing, clarify the comment on why text_format_nv wrapper is needed.

The new logic is less vulnerable to transpositions.

This invalidates the contents of hash indexes built with the old
functions; hence, bump catversion.

Dean Rasheed

The planner can sometimes compute very large values for numGroups, and in
cases where we have no alternative to building a hashtable, such a value
will get fed directly to BuildTupleHashTable as its nbuckets parameter.
There were two ways in which that could go bad.  First, BuildTupleHashTable
declared the parameter as "int" but most callers were passing "long"s,
so on 64-bit machines undetected overflow could occur leading to a bogus
negative value.  The obvious fix for that is to change the parameter to
"long", which is what I've done in HEAD.  In the back branches that seems a
bit risky, though, since third-party code might be calling this function.
So for them, just put in a kluge to treat negative inputs as INT_MAX.
Second, hash_create can go nuts with extremely large requested table sizes
(notably, my_log2 becomes an infinite loop for inputs larger than
LONG_MAX/2).  What seems most appropriate to avoid that is to bound the
initial table size request to work_mem.

This fixes bug #6035 reported by Daniel Schreiber.  Although the reported
case only occurs back to 8.4 since it involves WITH RECURSIVE, I think
it's a good idea to install the defenses in all supported branches.

Historically we didn't do this, even though we had the information, because
plpgsql passed its Params via SPI APIs that only include type OIDs not
typmods.  Now that plpgsql uses parser callbacks to create Params, it's
easy to insert the right typmod.  This should generally result in lower
surprise factors, because a plpgsql variable that is declared with a typmod
will now work more like a table column with the same typmod.  In particular
it's the "right" way to fix bug #6020, in which plpgsql's attempt to return
an anonymous record type is defeated by stricter record-type matching
checks that were added in 9.0.  However, it's not impossible that this
could result in subtle behavioral changes that could break somebody's
existing plpgsql code, so I'm afraid to back-patch this change into
released branches.  In those branches we'll have to lobotomize the
record-type checks instead.