Rename various "freeze multixact" variables

It seems to make more sense to use "cutoff multixact" terminology
throughout the backend code; "freeze" is associated with replacing of an
Xid with FrozenTransactionId, which is not what we do for MultiXactIds.

Andres Freund
Some adjustments by Álvaro Herrera

Add a GUC to report whether data page checksums are enabled.

Bernd Helmle

Fix typos

Ignore interrupts during quickdie().

Once the administrator has called for an immediate shutdown or a backend
crash has triggered a reinitialization, no mere SIGINT or SIGTERM should
change that course.  Such derailment remains possible when the signal
arrives before quickdie() blocks signals.  That being a narrow race
affecting most PostgreSQL signal handlers in some way, leave it for
another patch.  Back-patch this to all supported versions.

Create index on srt table in citext regression tests.

Comments and the tests make clear that the intent is to test with
and without an index, but there was no index.

fuzzystrmatch: replace broken link in C comment

Albe Laurenz

docs:  Update libpq and testlo examples

Josh Kupershmidt

Add comment for VARSIZE_ANY_EXHDR macro

Gurjeet Singh

psql: fix \copy stdin trailing space requirement

Previously a trailing space was required for \copy ... stdin:

copy foo from stdin ;

Etsuro Fujita

psql: honor 'footer' option for expanded output

"No rows" previously only honored the tuples-only option.

Per report from Eli Mesika

Remove leftover function prototype.

The prototype for inval_twophase_postcommit wasn't removed when it's definition
was removed in efc16ea520679d713d98a2c7bf1453c4ff7b91ec / the initial HS commit.

Andres Freund

Show schemas in information_schema.schemata that the current has access to

Before, it would only show schemas that the current user owns.  Per
discussion, the new behavior is more useful and consistent for PostgreSQL.

Introduce InvalidCommandId.

This allows a 32-bit field to represent an *optional* command ID
without a separate flag bit.

Andres Freund

Return error if allocation of new element was not possible.

Found by Coverity.

Close file to no leak file descriptor memory. Found by Coverity.

intarray:  return empty zero-dimensional array for an empty array

Previously a one-dimensional empty array was returned, but its text
representation matched a zero-dimensional array, and there is no way to
dump/reload a one-dimensional empty array.

BACKWARD INCOMPATIBILITY

Per report from elein

Don't VALGRIND_PRINTF() each query string.

Doing so was helpful for some Valgrind usage and distracting for other
usage.  One can achieve the same effect by changing log_statement and
pointing both PostgreSQL and Valgrind logging to stderr.

Per gripe from Andres Freund.

Eliminate pg_rewrite.ev_attr column and related dead code.

Commit 95ef6a344821655ce4d0a74999ac49dd6af6d342 removed the
ability to create rules on an individual column as of 7.3, but
left some residual code which has since been useless.  This cleans
up that dead code without any change in behavior other than
dropping the useless column from the catalog.

Make catalog cache hash tables resizeable.

If the hash table backing a catalog cache becomes too full (fillfactor > 2),
enlarge it. A new buckets array, double the size of the old, is allocated,
and all entries in the old hash are moved to the right bucket in the new
hash.

This has two benefits. First, cache lookups don't get so expensive when
there are lots of entries in a cache, like if you access hundreds of
thousands of tables. Second, we can make the (initial) sizes of the caches
much smaller, which saves memory.

This patch dials down the initial sizes of the catcaches. The new sizes are
chosen so that a backend that only runs a few basic queries still won't need
to enlarge any of them.

Revert WAL posix_fallocate() patches.

This reverts commit 269e780822abb2e44189afaccd6b0ee7aefa7ddd
and commit 5b571bb8c8d2bea610e01ae1ee7bc05adcfff528.

Unfortunately, the initial patch had insufficient performance testing,
and resulted in a regression.

Per report by Thom Brown.

Improve Range Types and Exclusion Constraints example.

Make the examples self-contained to avoid confusion. Per bug report
8367 from KOIZUMI Satoru.

Add GUC descriptions for compile-time postgresql.conf settings

Previous text was "No description available".

Tianyin Xu

Remove dead URL mention in OSX startup script

Backpatch to 9.3.

Per suggestion from Gavan Schneider

Keep heavily-contended fields in XLogCtlInsert on different cache lines.

Performance testing shows that if the insertpos_lck spinlock and the fields
that it protects are on the same cache line with other variables that are
frequently accessed, the false sharing can hurt performance a lot. Keep
them apart by adding some padding.

Expose fsync_fname as a public API.

Andres Freund

Update comments concerning PGC_S_TEST.

This GUC context value was once only used by ALTER DATABASE SET and
ALTER USER SET.  That's not true anymore, though, so rewrite the
comments to be a bit more general.

Patch in HEAD only, since this is just an internal documentation issue.

Don't fail for bad GUCs in CREATE FUNCTION with check_function_bodies off.

The previous coding attempted to activate all the GUC settings specified
in SET clauses, so that the function validator could operate in the GUC
environment expected by the function body.  However, this is problematic
when restoring a dump, since the SET clauses might refer to database
objects that don't exist yet.  We already have the parameter
check_function_bodies that's meant to prevent forward references in
function definitions from breaking dumps, so let's change CREATE FUNCTION
to not install the SET values if check_function_bodies is off.

Authors of function validators were already advised not to make any
"context sensitive" checks when check_function_bodies is off, if indeed
they're checking anything at all in that mode.  But extend the
documentation to point out the GUC issue in particular.

(Note that we still check the SET clauses to some extent; the behavior
with !check_function_bodies is now approximately equivalent to what ALTER
DATABASE/ROLE have been doing for awhile with context-dependent GUCs.)

This problem can be demonstrated in all active branches, so back-patch
all the way.

Allow aggregate functions to be VARIADIC.

There's no inherent reason why an aggregate function can't be variadic
(even VARIADIC ANY) if its transition function can handle the case.
Indeed, this patch to add the feature touches none of the planner or
executor, and little of the parser; the main missing stuff was DDL and
pg_dump support.

It is true that variadic aggregates can create the same sort of ambiguity
about parameters versus ORDER BY keys that was complained of when we
(briefly) had both one- and two-argument forms of string_agg().  However,
the policy formed in response to that discussion only said that we'd not
create any built-in aggregates with varying numbers of arguments, not that
we shouldn't allow users to do it.  So the logical extension of that is
we can allow users to make variadic aggregates as long as we're wary about
shipping any such in core.

In passing, this patch allows aggregate function arguments to be named, to
the extent of remembering the names in pg_proc and dumping them in pg_dump.
You can't yet call an aggregate using named-parameter notation.  That seems
like a likely future extension, but it'll take some work, and it's not what
this patch is really about.  Likewise, there's still some work needed to
make window functions handle VARIADIC fully, but I left that for another
day.

initdb forced because of new aggvariadic field in Aggref parse nodes.

Update obsolete comment

Docs: wording improvements in discussion of timestamp arithmetic.

I started out just to fix the broken markup in commit
1c2085766187031eaeaae7db4785b9e1d4241988, but got distracted by
copy-editing.  I see Bruce already fixed the markup, but I'll
commit the wordsmithing anyway.

doc:  Fix SGML markup for date patch

Docs:  add paragraph about date/timestamp subtraction

per suggestion from Francisco Olart

docs: Clarify that we also support Solaris versions greater than 10.

MauMau

Fix thinko in worker_spi, count(*) returns a bigint. Thanks RhodiumToad

Fix typo in comment.

Also line-wrap an over-wide line in a comment that's ignored by pgindent.

Update time zone data files to tzdata release 2013d.

DST law changes in Israel, Morocco, Palestine, Paraguay.
Historical corrections for Macquarie Island.

Fix relfrozenxid query in docs to include TOAST tables.

The original query ignored TOAST tables which could result in tables
needing a vacuum not being reported.

Backpatch to all live branches.

Translation updates

Update "Using EXPLAIN" documentation examples using current code.

It seems like a good idea to update these examples since some fairly
basic planner behaviors have changed in 9.3; notably that the startup cost
for an indexscan plan node is no longer invariably estimated at 0.00.

Update 9.3 release notes.

Some corrections, a lot of copy-editing.

Set projected release date as 2013-09-09.

Improve regression test for #8410.

The previous version of the query disregarded the result of the MergeAppend
instead of checking its results.

Andres Freund

Add test case for bug #8410.

Per Andres Freund.

Reset the binary heap in MergeAppend rescans.

Failing to do so can cause queries to return wrong data, error out or crash.
This requires adding a new binaryheap_reset() method to binaryheap.c,
but that probably should have been there anyway.

Per bug #8410 from Terje Elde.  Diagnosis and patch by Andres Freund.

Make error wording more consistent

Use a non-locking initial test in TAS_SPIN on x86_64.

Testing done in 2011 by Tom Lane concluded that this is a win on Intel Xeons
and AMD Opterons, but it was not changed back then, because of an old
comment in tas() that suggested that it's a huge loss on older Opterons.
However, didn't have separate TAS() and TAS_SPIN() macros back then, so the
comment referred to doing a non-locked initial test even on the first
access, in uncontended case. I don't have access to older Opterons, but I'm
pretty sure that doing an initial unlocked test is unlikely to be a loss
while spinning, even though it might be for the first access.

We probably should do the same on 32-bit x86, but I'm afraid of changing it
without any testing. Hence just add a note to the x86 implementation
suggesting that we probably should do the same there.

Allow discovery of whether a dynamic background worker is running.

Using the infrastructure provided by this patch, it's possible either
to wait for the startup of a dynamically-registered background worker,
or to poll the status of such a worker without waiting.  In either
case, the current PID of the worker process can also be obtained.
As usual, worker_spi is updated to demonstrate the new functionality.

Patch by me.  Review by Andres Freund.

Partially restore comments discussing enum renumbering hazards.

As noted by Tom Lane, commit 813fb0315587d32e3b77af1051a0ef517d187763
was overly optimistic about how safe it is to concurrently change
enumsortorder values under MVCC catalog scan semantics.  Restore
some of the previous text, with hopefully-correct adjustments for
the new state of play.

Accept multiple -I, -P, -T and -n options in pg_restore.

We already did this for -t (--table) in 9.3, but missed the other similar
options. For consistency, allow all of them to be specified multiple times.

Unfortunately it's too late to sneak this into 9.3, so commit to master
only.

Initialize cached OID to Invalid in new hash entries

Andres Freund; bug detected by valgrind

Fix some "translator:" comments mangled by pgindent

doc: Explain that ereport doesn't return for ERROR or higher levels.

Christophe Pettus

Account better for planning cost when choosing whether to use custom plans.

The previous coding in plancache.c essentially used 10% of the estimated
runtime as its cost estimate for planning.  This can be pretty bogus,
especially when the estimated runtime is very small, such as in a simple
expression plan created by plpgsql, or a simple INSERT ... VALUES.

While we don't have a really good handle on how planning time compares
to runtime, it seems reasonable to use an estimate based on the number of
relations referenced in the query, with a rather large multiplier.  This
patch uses 1000 * cpu_operator_cost * (nrelations + 1), so that even a
trivial query will be charged 1000 * cpu_operator_cost for planning.
This should address the problem reported by Marc Cousin and others that
9.2 and up prefer custom plans in cases where the planning time greatly
exceeds what can be saved.

Don't crash when pg_xlog is empty and pg_basebackup -x is used

The backup will not work (without a logarchive, and that's the whole
point of -x) in this case, this patch just changes it to throw an
error instead of crashing when this happens.

Noticed and diagnosed by TAKATSUKA Haruka

In locate_grouping_columns(), don't expect an exact match of Var typmods.

It's possible that inlining of SQL functions (or perhaps other changes?)
has exposed typmod information not known at parse time.  In such cases,
Vars generated by query_planner might have valid typmod values while the
original grouping columns only have typmod -1.  This isn't a semantic
problem since the behavior of grouping only depends on type not typmod,
but it breaks locate_grouping_columns' use of tlist_member to locate the
matching entry in query_planner's result tlist.

We can fix this without an excessive amount of new code or complexity by
relying on the fact that locate_grouping_columns only gets called when
make_subplanTargetList has set need_tlist_eval == false, and that can only
happen if all the grouping columns are simple Vars.  Therefore we only need
to search the sub_tlist for a matching Var, and we can reasonably define a
"match" as being a match of the Var identity fields
varno/varattno/varlevelsup.  The code still Asserts that vartype matches,
but ignores vartypmod.

Per bug #8393 from Evan Martin.  The added regression test case is
basically the same as his example.  This has been broken for a very long
time, so back-patch to all supported branches.

Fix hash table size estimation error in choose_hashed_distinct().

We should account for the per-group hashtable entry overhead when
considering whether to use a hash aggregate to implement DISTINCT.  The
comparable logic in choose_hashed_grouping() gets this right, but I think
I omitted it here in the mistaken belief that there would be no overhead
if there were no aggregate functions to be evaluated.  This can result in
more than 2X underestimate of the hash table size, if the tuples being
aggregated aren't very wide.  Per report from Tomas Vondra.

This bug is of long standing, but per discussion we'll only back-patch into
9.3.  Changing the estimation behavior in stable branches seems to carry too
much risk of destabilizing plan choices for already-tuned applications.

docs: Remove second 'trim' index reference

Per suggestion from Vik Fearing

Unconditionally use the WSA equivalents of Socket error constants.

This change will only apply to mingw compilers, and has been found
necessary by late versions of the mingw-w64 compiler. It's the same as
what is done elsewhere for the Microsoft compilers.

If this doesn't upset older compilers in the buildfarm, it will be
backpatched to 9.1.

Problem reported by Michael Cronenworth, although not his patch.

release notes: update link to 9.3 PL/pgSQL constraint error info

Backpatch to 9.3.

Pavel Stehule

Be more wary of unwanted whitespace in pgstat_reset_remove_files().

sscanf isn't the easiest thing to use for exact pattern checks ...
also, don't use strncmp where strcmp will do.

Fix removal of files in pgstats directories

Instead of deleting all files in stats_temp_directory and the permanent
directory on a crash, only remove those files that match the pattern of
files we actually write in them, to avoid possibly clobbering existing
unrelated contents of the temporary directory.  Per complaint from Jeff
Janes, and subsequent discussion, starting at message
CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com

Also, fix a bug in the same routine to avoid removing files from the
permanent directory twice (instead of once from that directory and then
from the temporary directory), also per report from Jeff Janes, in
message
CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com

Rename the "fast_promote" file to just "promote".

This keeps the usual trigger file name unchanged from 9.2, avoiding nasty
issues if you use a pre-9.3 pg_ctl binary with a 9.3 server or vice versa.
The fallback behavior of creating a full checkpoint before starting up is now
triggered by a file called "fallback_promote". That can be useful for
debugging purposes, but we don't expect any users to have to resort to that
and we might want to remove that in the future, which is why the fallback
mechanism is undocumented.

Fix qual-clause-misplacement issues with pulled-up LATERAL subqueries.

In an example such as
SELECT * FROM
  i LEFT JOIN LATERAL (SELECT * FROM j WHERE i.n = j.n) j ON true;
it is safe to pull up the LATERAL subquery into its parent, but we must
then treat the "i.n = j.n" clause as a qual clause of the LEFT JOIN.  The
previous coding in deconstruct_recurse mistakenly labeled the clause as
"is_pushed_down", resulting in wrong semantics if the clause were applied
at the join node, as per an example submitted awhile ago by Jeremy Evans.
To fix, postpone processing of such clauses until we return back up to
the appropriate recursion depth in deconstruct_recurse.

In addition, tighten the is-safe-to-pull-up checks in is_simple_subquery;
we previously missed the possibility that the LATERAL subquery might itself
contain an outer join that makes lateral references in lower quals unsafe.

A regression test case equivalent to Jeremy's example was already in my
commit of yesterday, but was giving the wrong results because of this
bug.  This patch fixes the expected output for that, and also adds a
test case for the second problem.

Fix pg_upgrade failure from servers older than 9.3

When upgrading from servers of versions 9.2 and older, and MultiXactIds
have been used in the old server beyond the first page (that is, 2048
multis or more in the default 8kB-page build), pg_upgrade would set the
next multixact offset to use beyond what has been allocated in the new
cluster.  This would cause a failure the first time the new cluster
needs to use this value, because the pg_multixact/offsets/ file wouldn't
exist or wouldn't be large enough.  To fix, ensure that the transient
server instances launched by pg_upgrade extend the file as necessary.

Per report from Jesse Denardo in
CANiVXAj4c88YqipsyFQPboqMudnjcNTdB3pqe8ReXqAFQ=HXyA@mail.gmail.com

release notes: remove username from 9.3 major item

Etsuro Fujita

Translation updates

Remove relcache entry invalidation in REFRESH MATERIALIZED VIEW.

This was added as part of the attempt to support unlogged matviews
along with a populated status.  It got missed when unlogged
support was removed pre-commit.

Noticed by Noah Misch.  Back-patched to 9.3 branch.

libpq: Report strerror on pthread_mutex_lock() failure

Fix thinko in comment.

Fix planner problems with LATERAL references in PlaceHolderVars.

The planner largely failed to consider the possibility that a
PlaceHolderVar's expression might contain a lateral reference to a Var
coming from somewhere outside the PHV's syntactic scope.  We had a previous
report of a problem in this area, which I tried to fix in a quick-hack way
in commit 4da6439bd8553059766011e2a42c6e39df08717f, but Antonin Houska
pointed out that there were still some problems, and investigation turned
up other issues.  This patch largely reverts that commit in favor of a more
thoroughly thought-through solution.  The new theory is that a PHV's
ph_eval_at level cannot be higher than its original syntactic level.  If it
contains lateral references, those don't change the ph_eval_at level, but
rather they create a lateral-reference requirement for the ph_eval_at join
relation.  The code in joinpath.c needs to handle that.

Another issue is that createplan.c wasn't handling nested PlaceHolderVars
properly.

In passing, push knowledge of lateral-reference checks for join clauses
into join_clause_is_movable_to.  This is mainly so that FDWs don't need
to deal with it.

This patch doesn't fix the original join-qual-placement problem reported by
Jeremy Evans (and indeed, one of the new regression test cases shows the
wrong answer because of that).  But the PlaceHolderVar problems need to be
fixed before that issue can be addressed, so committing this separately
seems reasonable.

release notes: update 9.3 major feature list

Backpatch to 9.3.

release notes: Update to 9.3 git current

Backpatch to 9.3, of course.

Move more bgworker code to bgworker.c; also, some renaming.

Per discussion on pgsql-hackers.

Michael Paquier, slightly modified by me.  Original suggestion
from Amit Kapila.

pg_upgrade: shut down server after auth failure

Register atexit() server shutdown if pg_ctl successfully started the
server, but we can't connect to it.

Backpatch to 9.3.

Pavel Raiskup

Fix typo in comment.

Don't allow ALTER MATERIALIZED VIEW ADD UNIQUE.

Was accidentally allowed, but not documented and lacked support
for rename or drop once created.

Per report from Noah Misch.

Add tab completion for \dx in psql

Treat timeline IDs as unsigned in replication parser

Timeline IDs are unsigned ints everywhere, except the replication parser
treated them as signed ints.

Improve error message when view is not updatable

Avoid using the term "updatable" in confusing ways.  Suggest a trigger
first, before a rule.

Remove ph_may_need from PlaceHolderInfo, with attendant simplifications.

The planner logic that attempted to make a preliminary estimate of the
ph_needed levels for PlaceHolderVars seems to be completely broken by
lateral references.  Fortunately, the potential join order optimization
that this code supported seems to be of relatively little value in
practice; so let's just get rid of it rather than trying to fix it.

Getting rid of this allows fairly substantial simplifications in
placeholder.c, too, so planning in such cases should be a bit faster.

Issue noted while pursuing bugs reported by Jeremy Evans and Antonin
Houska, though this doesn't in itself fix either of their reported cases.
What this does do is prevent an Assert crash in the kind of query
illustrated by the added regression test.  (I'm not sure that the plan for
that query is stable enough across platforms to be usable as a regression
test output ... but we'll soon find out from the buildfarm.)

Back-patch to 9.3.  The problem case can't arise without LATERAL, so
no need to touch older branches.

docs:  document TRIM "comma" syntax

This syntax is supported by the parser, but is non-standard.

_Not_ backpatched to 9.3 in case we change our minds.

Remove Assert that matview is not in system schema from REFRESH.

We don't want to prevent an extension which creates a matview from
being installed in pg_catalog.

Issue was raised by Hitoshi Harada.
Backpatched to 9.3.

Update Emacs configuration

Update emacs.samples with new configuration snippets that match pgindent
et al. formatting more accurately and follow Emacs Lisp best practices
better.

Add .dir-locals.el with a subset of that configuration for casual
editing and viewing.

Reviewed-by: Dimitri Fontaine <dimitri@2ndQuadrant.fr>
Reviewed-by: Noah Misch <noah@leadboat.com>

Emit a log message if output is about to be redirected away from stderr.

We've seen multiple cases of people looking at the postmaster's original
stderr output to try to diagnose problems, not realizing/remembering that
their logging configuration is set up to send log messages somewhere else.
This seems particularly likely to happen in prepackaged distributions,
since many packagers patch the code to change the factory-standard logging
configuration to something more in line with their platform conventions.

In hopes of reducing confusion, emit a LOG message about this at the point
in startup where we are about to switch log output away from the original
stderr, providing a pointer to where to look instead.  This message will
appear as the last thing in the original stderr output.  (We might later
also try to emit such link messages when logging parameters are changed
on-the-fly; but that case seems to be both noticeably harder to do nicely,
and much less frequently a problem in practice.)

Per discussion, back-patch to 9.3 but not further.

9.3 release notes:  move foreign table item

Move item about foreign data wrappers supporting inserts/updates/deletes
to object manipulation.

From Etsuro Fujita

pg_dump:  avoid schema qualification for ALTER ... OWNER

We already use search_path to specify the schema, so there is no need
for pg_dump to schema-qualify the name.  Also remove dead code.

PL/Python: Adjust the regression tests for Python 3.3

Similar to 2cfb1c6f77734db81b6e74bcae630f93b94f69be, the order in which
dictionary elements are printed is not reliable.  This reappeared in the
tests of the string representation of result objects.  Reduce the test
case to one result set column so that there is no question of order.

docs:  mention Julian is midnight _UTC_
(Yes, there was no UTC back then, but we compute it that way.)
Backpatch to 9.3.

Docs:  Document to_*() Julian values are integers
Backpatch to 9.3.
Per request from Marc Dahn

Document how auto_explain.log_timing can be changed.

Message punctuation and pluralization fixes

Message style improvements

Fix assertion failure by an immediate shutdown.

In PM_WAIT_DEAD_END state, checkpointer process must be dead already.
But an immediate shutdown could make postmaster's state machine
transition to PM_WAIT_DEAD_END state even if checkpointer process is
still running,  and which caused assertion failure. This bug was introduced
in commit 457d6cf049c57cabe9b46ea13f26138040a214ec.

This patch ensures that postmaster's state machine doesn't transition to
PM_WAIT_DEAD_END state in an immediate shutdown while checkpointer
process is running.

pgtest:  allow passing parameters, e.g. -s/--silent
Previously only -n was recognized.

Simplify query_planner's API by having it return the top-level RelOptInfo.

Formerly, query_planner returned one or possibly two Paths for the topmost
join relation, so that grouping_planner didn't see the join RelOptInfo
(at least not directly; it didn't have any hesitation about examining
cheapest_path->parent, though).  However, correct selection of the Paths
involved a significant amount of coupling between query_planner and
grouping_planner, a problem which has gotten worse over time.  It seems
best to give up on this API choice and instead return the topmost
RelOptInfo explicitly.  Then grouping_planner can pull out the Paths it
wants from the rel's path list.  In this way we can remove all knowledge
of grouping behaviors from query_planner.

The only real benefit of the old way is that in the case of an empty
FROM clause, we never made any RelOptInfos at all, just a Path.  Now
we have to gin up a dummy RelOptInfo to represent the empty FROM clause.
That's not a very big deal though.

While at it, simplify query_planner's API a bit more by having the caller
set up root->tuple_fraction and root->limit_tuples, rather than passing
those values as separate parameters.  Since query_planner no longer does
anything with either value, requiring it to fill the PlannerInfo fields
seemed pretty arbitrary.

This patch just rearranges code; it doesn't (intentionally) change any
behaviors.  Followup patches will do more interesting things.

Various cleanups for REFRESH MATERIALIZED VIEW CONCURRENTLY.

Open and lock each index before checking definition in RMVC.  The
ExclusiveLock on the related table is not viewed as sufficient to
ensure that no changes are made to the index definition, and
invalidation messages from other backends might have been missed.
Additionally, use RelationGetIndexExpressions() and check for NIL
rather than doing our own loop.

Protect against redefinition of tid and rowvar operators in RMVC.
While working on this, noticed that the fixes for bugs found during
the CF made the UPDATE statement useless, since no rows could
qualify for that treatment any more.  Ripping out code to support
the UPDATE statement simplified the operator cleanups.

Change slightly confusing local field name.

Use meaningful alias names on queries in refresh_by_match_merge().

Per concerns of raised by Andres Freund and comments and
suggestions from Noah Misch.  Some additional issues remain, which
will be addressed separately.

Make sure float4in/float8in accept all standard spellings of "infinity".

The C99 and POSIX standards require strtod() to accept all these spellings
(case-insensitively): "inf", "+inf", "-inf", "infinity", "+infinity",
"-infinity".  However, pre-C99 systems might accept only some or none of
these, and apparently Windows still doesn't accept "inf".  To avoid
surprising cross-platform behavioral differences, manually check for each
of these spellings if strtod() fails.  We were previously handling just
"infinity" and "-infinity" that way, but since C99 is most of the world
now, it seems likely that applications are expecting all these spellings
to work.

Per bug #8355 from Basil Peace.  It turns out this fix won't actually
resolve his problem, because Python isn't being this careful; but that
doesn't mean we shouldn't be.

Fix old visibility bug in HeapTupleSatisfiesDirty

If a tuple is locked but not updated by a concurrent transaction,
HeapTupleSatisfiesDirty would return that transaction's Xid in xmax,
causing callers to wait on it, when it is not necessary (in fact, if the
other transaction had used a multixact instead of a plain Xid to mark
the tuple, HeapTupleSatisfiesDirty would have behave differently and
*not* returned the Xmax).

This bug was introduced in commit 3f7fbf85dc5b42, dated December 1998,
so it's almost 15 years old now.  However, it's hard to see this
misbehave, because before we had NOWAIT the only consequence of this is
that transactions would wait for slightly more time than necessary; so
it's not surprising that this hasn't been reported yet.

Craig Ringer and Andres Freund

Fix crash in error report of invalid tuple lock

My tweak of these error messages in commit c359a1b082 contained the
thinko that a query would always have rowMarks set for a query
containing a locking clause.  Not so: when declaring a cursor, for
instance, rowMarks isn't set at the point we're checking, so we'd be
dereferencing a NULL pointer.

The fix is to pass the lock strength to the function raising the error,
instead of trying to reverse-engineer it.  The result not only is more
robust, but it also seems cleaner overall.

Per report from Robert Haas.

Fix typo in comment.

Etsuro Fujita

pg_test_fsync: expand ops/sec display
Expand ops/sec by two digits to maintain alignment on servers with fast
I/O subsystems, e.g. can now display < 10M ops/sec with consistent
alignment.