Fix lo_import and lo_export to return useful error messages more often.

I found that these functions tend to return -1 while leaving an empty error
message string in the PGconn, if they suffer some kind of I/O error on the
file.  The reason is that lo_close, which thinks it's executed a perfectly
fine SQL command, clears the errorMessage.  The minimum-change workaround
is to reorder operations here so that we don't fill the errorMessage until
after lo_close.
Add microsecs/op display to pg_test_fsync utility

e.g. fsync  2103.613 ops/sec (   475 microsecs/op)

Peter Geoghegan
Use tablespace_option consistently on doc page

Fujii Masao
Remove stray newline in comment.
Rename USE_INLINE to PG_USE_INLINE

The former name was too likely to conflict with symbols from external
headers; and, as seen in recent buildfarm failures in member spoonbill,
it has now happened at least in plpython.
restore permission bits
Put the logic to wait for WAL in standby mode to a separate function.

This is just refactoring with no user-visible effect, to make the code more
readable.
Fix silly bug in previous refactoring.

I extracted the refactoring patch from a larger patch that contained other
changes too, but missed one unintentional change and didn't test enough...
Remove unnecessary overhead in backend's large-object operations.

Do read/write permissions checks at most once per large object descriptor,
not once per lo_read or lo_write call as before.  The repeated tests were
quite useless in the read case since the snapshot-based tests were
guaranteed to produce the same answer every time.  In the write case,
the extra tests could in principle detect revocation of write privileges
after a series of writes has started --- but there's a race condition there
anyway, since we'd check privileges before performing and certainly before
committing the write.  So there's no real advantage to checking every
single time, and we might as well redefine it as "only check the first
time".

On the same reasoning, remove the LargeObjectExists checks in inv_write
and inv_truncate.  We already checked existence when the descriptor was
opened, and checking again doesn't provide any real increment of safety
that would justify the cost.
Fix PGXS support for building loadable modules on AIX.

Building a shlib on AIX requires use of the mkldexport.sh script, but we
failed to install that, preventing its use from non-source-tree contexts.
Also, Makefile.aix had the wrong idea about where to find the installed
copy of the postgres.imp symbol file used by AIX.

Per report from John Pierce.  Patch all the way back, since this has been
broken since the beginning of PGXS.
Set procost to 10 for each of the pg_foo_is_visible() functions.

The idea here is to make sure the planner will evaluate these functions
last not first among the filter conditions in psql pattern search and
tab-completion queries.  We've discussed this several times, and there
was consensus to do it back in August, but we didn't want to do it just
before a release.  Now seems like a safer time.

No catversion bump, since this catalog change doesn't create a backend
incompatibility nor any regression test result changes.
In pg_upgrade, issue proper error message when we can't open PG_VERSION.

Backpatch to 9.2.
Update obsolete text in fdwhandler.sgml.

Etsuro Fujita, with some wording adjustment by me.
Create an improved FDW option validator function for contrib/dblink.

dblink now has its own validator function dblink_fdw_validator(), which is
better than the core function postgresql_fdw_validator() because it gets
the list of legal options from libpq instead of having a hard-wired list.

Make the dblink extension module provide a standard foreign data wrapper
dblink_fdw that encapsulates use of this validator, and recommend use of
that wrapper instead of making up wrappers on the fly.

Unfortunately, because ad-hoc wrappers *were* recommended practice
previously, it's not clear when we can get rid of postgresql_fdw_validator
without causing upgrade problems.  But this is a step in the right
direction.

Shigeru Hanada, reviewed by KaiGai Kohei
Update obsolete comment.

We no longer use GetNewOidWithIndex on pg_largeobject; rather,
pg_largeobject_metadata's regular OID column is considered the repository
of OIDs for large objects.  The special functionality is still needed for
TOAST tables however.