Use improved vsnprintf calling logic in more places.

When we are using a C99-compliant vsnprintf implementation (which should be
most places, these days) it is worth the trouble to make use of its report
of how large the buffer needs to be to succeed.  This patch adjusts
stringinfo.c and some miscellaneous usages in pg_dump to do that, relying
on the logic recently added in libpgcommon's psprintf.c.  Since these
places want to know the number of bytes written once we succeed, modify the
API of pvsnprintf() to report that.

There remains near-duplicate logic in pqexpbuffer.c, but since that code
is in libpq, psprintf.c's approach of exit()-on-error isn't appropriate
for use there.  Also note that I didn't bother touching the multitude
of places that call (v)snprintf without any attempt to provide a resizable
buffer.

Release-note-worthy incompatibility: the API of appendStringInfoVA()
changed.  If there's any third-party code that's calling that directly,
it will need tweaking along the same lines as in this patch.

David Rowley and Tom Lane
Ignore SIGSYS during initdb.

This prevents the recently-added probe for shm_open() from crashing
on platforms that are impolite enough to deliver a signal rather than
returning ENOSYS for an unimplemented kernel call.  At least on the
one known example (HPUX 10.20), ignoring SIGSYS does result in the
desired behavior of getting an ENOSYS error return instead.

Per discussion, we might later wish to do this in the backend as well,
but for now it seems sufficient to do it in initdb.
Tweak "line" test to avoid negative zeros on some platforms
Revert "Tweak "line" test to avoid negative zeros on some platforms"

This reverts commit a0a546f0d94ec6cbb3cd6b1c82f58d801046615f.
It seems better to tweak the code to suppress -0 results during
line_construct_pts(), which I'll do in the next commit.
Suppress -0 in the C field of lines computed by line_construct_pts().

It's not entirely clear why some PPC machines are generating -0 here, since
the underlying computation should be exactly 0 - 0.  Perhaps there's some
wider-than-nominal-precision calculations happening?  Anyway, the best way
to avoid platform-dependent results seems to be to explicitly reset -0 to
regular zero.
Improve pqexpbuffer.c to use modern vsnprintf implementations efficiently.

When using a C99-compliant vsnprintf, we can use its report of the required
buffer size to avoid making multiple loops through the formatting logic.
This is similar to the changes recently made in stringinfo.c, but we can't
use psprintf.c here because in libpq we don't want to exit() on error.
(The behavior pqexpbuffer.c has historically used is to mark the
PQExpBuffer as "broken", ie empty, if it runs into any fatal problem.)

To avoid duplicating code more than necessary, I refactored
printfPQExpBuffer and appendPQExpBuffer to share a subroutine that's
very similar to psprintf.c's pvsnprintf in spirit.
Use unaligned output in selected regression queries to reduce diff noise.

The rules regression test prints all known views and rules, which is a set
that changes regularly.  Previously, a change in one rule would frequently
lead to whitespace changes across the entire output of this query, which is
painful to verify and causes undesirable conflicts between unrelated patch
sets.  Use \a mode to improve matters.  Also use \t mode to suppress the
total-rows count, which was also a source of unnecessary patch conflicts.

Likewise modify the output mode for the list of indexed tables generated
in sanity_check.sql.  There might be other places where we should use this
idea, but these are the ones that have caused the most problems.

Andres Freund
Add large object functions catering to SQL callers.

With these, one need no longer manipulate large object descriptors and
extract numeric constants from header files in order to read and write
large object contents from SQL.

Pavel Stehule, reviewed by Rushabh Lathia.
Suppress duplicate-index-entry warning introduced by previous commit.

We don't need two index entries for lo_create pointing at the same section.
It's a bit pedantic for the toolchain to warn about this, but warn it does.
Improve documentation about usage of FDW validator functions.

SGML documentation, as well as code comments, failed to note that an FDW's
validator will be applied to foreign-table options for foreign tables using
the FDW.

Etsuro Fujita
Work around NetBSD shell issue in pg_upgrade test script.

The NetBSD shell apparently returns non-zero from an unset command if
the variable is already unset. This matters when, as in pg_upgrade's
test.sh, we are working under 'set -e'. To protect against this, we
first set the PG variables to an empty string before unsetting them
completely.

Error found on buildfarm member coypu, solution from Rémi Zara.
Modify dynamic shared memory code to use Size rather than uint64.

This is more consistent with what we do elsewhere.
Prevent using strncpy with src == dest in TupleDescInitEntry.

The C and POSIX standards state that strncpy's behavior is undefined when
source and destination areas overlap.  While it remains dubious whether any
implementations really misbehave when the pointers are exactly equal, some
platforms are now starting to force the issue by complaining when an
undefined call occurs.  (In particular OS X 10.9 has been seen to dump core
here, though the exact set of circumstances needed to trigger that remain
elusive.  Similar behavior can be expected to be optional on Linux and
other platforms in the near future.)  So tweak the code to explicitly do
nothing when nothing need be done.

Back-patch to all active branches.  In HEAD, this also lets us get rid of
an exception in valgrind.supp.

Per discussion of a report from Matthias Schmitt.
Fix old typo in comment.

NFAs have children, but their individual states don't.
Avoid too-large shift on 32-bit Windows.

Apparently, shifts greater than or equal to the width of the type
are undefined, and can surprisingly produce a non-zero value.

Amit Kapila, with a comment by me.
Use appendStringInfoString instead of appendStringInfo where possible.

This shaves a few cycles, and generally seems like good programming
practice.

David Rowley
Fix some odd behaviors when using a SQL-style simple GMT offset timezone.

Formerly, when using a SQL-spec timezone setting with a fixed GMT offset
(called a "brute force" timezone in the code), the session_timezone
variable was not updated to match the nominal timezone; rather, all code
was expected to ignore session_timezone if HasCTZSet was true.  This is
of course obviously fragile, though a search of the code finds only
timeofday() failing to honor the rule.  A bigger problem was that
DetermineTimeZoneOffset() supposed that if its pg_tz parameter was
pointer-equal to session_timezone, then HasCTZSet should override the
parameter.  This would cause datetime input containing an explicit zone
name to be treated as referencing the brute-force zone instead, if the
zone name happened to match the session timezone that had prevailed
before installing the brute-force zone setting (as reported in bug #8572).
The same malady could affect AT TIME ZONE operators.

To fix, set up session_timezone so that it matches the brute-force zone
specification, which we can do using the POSIX timezone definition syntax
"<abbrev>offset", and get rid of the bogus lookaside check in
DetermineTimeZoneOffset().  Aside from fixing the erroneous behavior in
datetime parsing and AT TIME ZONE, this will cause the timeofday() function
to print its result in the user-requested time zone rather than some
previously-set zone.  It might also affect results in third-party
extensions, if there are any that make use of session_timezone without
considering HasCTZSet, but in all cases the new behavior should be saner
than before.

Back-patch to all supported branches.
Remove internal uses of CTimeZone/HasCTZSet.

The only remaining places where we actually look at CTimeZone/HasCTZSet
are abstime2tm() and timestamp2tm().  Now that session_timezone is always
valid, we can remove these special cases.  The caller-visible impact of
this is that these functions now always return a valid zone abbreviation
if requested, whereas before they'd return a NULL pointer if a brute-force
timezone was in use.  In the existing code, the only place I can find that
changes behavior is to_char(), whose TZ format code will now print
something useful rather than nothing for such zones.  (In the places where
the returned zone abbreviation is passed to EncodeDateTime, the lack of
visible change is because we've chosen the abbreviation used for these
zones to match what EncodeTimezone would have printed.)

It's likely that there is now a fair amount of removable dead code around
the call sites, namely anything that's meant to cope with getting a NULL
timezone abbreviation, but I've not made an effort to root that out.

This could be back-patched if we decide we'd like to fix to_char()'s
behavior in the back branches, but there doesn't seem to be much
enthusiasm for that at present.
Remove CTimeZone/HasCTZSet, root and branch.

These variables no longer have any useful purpose, since there's no reason
to special-case brute force timezones now that we have a valid
session_timezone setting for them.  Remove the variables, and remove the
SET/SHOW TIME ZONE code that deals with them.

The user-visible impact of this is that SHOW TIME ZONE will now show a
POSIX-style zone specification, in the form "<+-offset>-+offset", rather
than an interval value when a brute-force zone has been set.  While perhaps
less intuitive, this is a better definition than before because it's
actually possible to give that string back to SET TIME ZONE and get the
same behavior, unlike what used to happen.

We did not previously mention the angle-bracket syntax when describing
POSIX timezone specifications; add some documentation so that people
can figure out what these strings do.  (There's still quite a lot of
undocumented functionality there, but anybody who really cares can
go read the POSIX spec to find out about it.  In practice most people
seem to prefer Olsen-style city names anyway.)
Ensure all files created for a single BufFile have the same resource owner.

Callers expect that they only have to set the right resource owner when
creating a BufFile, not during subsequent operations on it.  While we could
insist this be fixed at the caller level, it seems more sensible for the
BufFile to take care of it.  Without this, some temp files belonging to
a BufFile can go away too soon, eg at the end of a subtransaction,
leading to errors or crashes.

Reported and fixed by Andres Freund.  Back-patch to all active branches.