Fix obsolete config-module-exclusion logic in vcregress.pl.

The recent addition of regression tests to uuid-ossp exposed the fact
that the MSVC build system wasn't being consistent about whether it was
building/testing that contrib module, ie, it would try to test the module
even when it hadn't built it.  The same hazard was latent for sslinfo.

For the moment I just copied the more up-to-date logic from point A to
point B, but this is screaming for refactoring.

Per buildfarm results.

Propagate system identifier generation improvement into pg_resetxlog.

Commit 5035701e07e8bd395aa878465a102afd7b74e8c3 improved xlog.c's method
for creating a database system identifier, but I neglected to fix the
copy of that code appearing in pg_resetxlog.c.  Spotted by Andres Freund.

doc:  improve ssl_ecdh_curve descriptions

Patch by Marko Kreen

Support BSD and e2fsprogs UUID libraries alongside OSSP UUID library.

Allow the contrib/uuid-ossp extension to be built atop any one of these
three popular UUID libraries.  (The extension's name is now arguably a
misnomer, but we'll keep it the same so as not to cause unnecessary
compatibility issues for users.)

We would not normally consider a change like this post-beta1, but the issue
has been forced by our upgrade to autoconf 2.69, whose more rigorous header
checks are causing OSSP's header files to be rejected on some platforms.
It's been foreseen for some time that we'd have to move away from depending
on OSSP UUID due to lack of upstream maintenance, so this is a down payment
on that problem.

While at it, add some simple regression tests, in hopes of catching any
major incompatibilities between the three implementations.

Matteo Beccati, with some further hacking by me

worker_spi: Initialize bgw_notify_pid in all cases.

Commit 090d0f2050647958865cb495dff74af7257d2bb4 added new code showing
how it can be useful to set bgw_notify_pid to a non-zero value, but it
failed to make sure that the existing call to RegisterBackgroundWorker
initialized the new field at all.

Report and patch by Shigeru Hanada.

Avoid unportable usage of sscanf(UINT64_FORMAT).

On Mingw, it seems that scanf() doesn't necessarily accept the same format
codes that printf() does, and in particular it may fail to recognize %llu
even though printf() does.  Since configure only probes printf() behavior
while setting up the INT64_FORMAT macros, this means it's unsafe to use
those macros with scanf().  We had only one instance of such a coding
pattern, in contrib/pg_stat_statements, so change that code to avoid
the problem.

Per buildfarm warnings.  Back-patch to 9.0 where the troublesome code
was introduced.

Michael Paquier

Fix pg_recvlogical to accept the documented -I instead only --startpos.

The bug was caused by omitting 'I:' from the short argument list to
getopt_long(). To make similar bugs in the future less likely reorder
options in --help, long and short option lists to be in the same,
alphabetical within groups, order.

Report and fix by Michael Paquier, some additional reordering by me.

Small typo and formatting fixes in postgresql.conf.sample

Fix error when trying to delete page with half-dead left sibling.

The new page deletion code didn't cope with the case the target page's
right sibling was marked half-dead. It failed a sanity check which checked
that the downlinks in the parent page match the lower level, because a
half-dead page has no downlink. To cope, check for that condition, and
just give up on the deletion if it happens. The vacuum will finish the
deletion of the half-dead page when it gets there, and on the next vacuum
after that the empty can be deleted.

Reported by Jeff Janes.

Allow total number of transactions in pgbench to exceed INT_MAX.

Change the total-transactions counters from int32 to int64 to accommodate
cases where we do more than 2^31 transactions during a run.  This patch
does not change the INT_MAX limit on explicit "-t" parameters, but it
does allow the product of the -t and -c parameters to exceed INT_MAX, or
allow a -T limit that is large enough that more than 2^31 transactions
can be completed.  While pgbench did not actually fail in such cases,
it did print an incorrect total-transactions count, and some of the
derived numbers such as TPS would have been wrong as well.

Tomas Vondra

Don't allocate memory inside an Assert() iff in a critical section.

HeapTupleHeaderGetCmax() asserts that it is only used if the tuple has
been updated by the current transaction. That check is correct and
sensible but requires allocating memory if xmax is a multixact. When
wal_level is set to logical cmax needs to be included in a wal record
, generated inside a critical section, which can trigger the assertion
added in 4a170ee9e.

Reported-By: Steve Singer

Silence a couple of spurious valgrind warnings in inval.c.

Define padding bytes in SharedInvalidationMessage structs to be
defined. Otherwise the sinvaladt.c ringbuffer, which is accessed by
multiple processes, will cause spurious valgrind warnings about
undefined memory being used. That's because valgrind remembers the
undefined bytes from the last local process's store, not realizing
that another process has written since, filling the previously
uninitialized bytes.

doc:  link/caps fixes for 9.4 release notes

Report by Tomonari Katsumata

Fix misc typos in comments.

Remove unnecessary cleanup code.

This is all inside a block guarded by op == DSM_OP_ATTACH, so it can
never be the case that op == DSM_OP_CREATE.

Reported by Coverity.

Fix typo in comment.

Erik Rijkers

Fix typos in comments.

Fix typos in comments.

doc:  add ALTER TABLE lock level item as major 9.4 item

Report by Simon Riggs

Fix spurious tab character

doc:  9.4 release notes update for pg_bench line limit item

Report by David Johnston

Prevent auto_explain from changing the output of a user's EXPLAIN.

Commit af7914c6627bcf0b0ca614e9ce95d3f8056602bf, which introduced the
EXPLAIN (TIMING) option, for some reason coded explain.c to look at
planstate->instrument->need_timer rather than es->timing to decide
whether to print timing info.  However, the former flag might get set
as a result of contrib/auto_explain wanting timing information.  We
certainly don't want activation of auto_explain to change user-visible
statement behavior, so fix that.

Also fix an independent bug introduced in the same patch: in the code
path for a never-executed node with a machine-friendly output format,
if timing was selected, it would fail to print the Actual Rows and Actual
Loops items.

Per bug #10404 from Tomonari Katsumata.  Back-patch to 9.2 where the
faulty code was introduced.

Update obsolete comment.

Peter Geoghegan

Fix typo in JSON function document.

Message style fixes to pg_recvlogical

Lowercase help statements. Use an existing message to reduce the number
of strings to be translated.

Euler Taveira

Fix backup-block numbering in redo of b-tree split.

I got the backup block numbers off-by-one in the commit that changed the
way incomplete-splits are handled. I blame the comments, which said
"backup block 1" and "backup block 2", even though the backup blocks
are numbered starting from 0, in the macros and functions used in replay.
Fix the comments and the code.

Per Jeff Janes' bug report about corruption caused by torn page writes.
The incorrect code is new in git master, but backpatch the comment change
down to 9.0, where the numbering in the redo-side macros  was changed.

Fix incorrect column name in pg_stat_replication document.

Fabrízio de Royes Mello

doc:  adjust JSONB 9.4 release note item

Report by Andrew Dunstan

doc:  9.4 release note adjustements

Text from David G Johnston

Fix non-C89-compatible coding in pgbench.

C89 says that compound initializers may only contain constant expressions;
a restriction violated by commit 89d00cbe.  While we've had no actual field
complaints about this, C89 is still the project standard, and it's not
saving all that much code to break compatibility here.  So let's adhere to
the old restriction.

In passing, replace a bunch of hardwired constants "256" with
sizeof(target-variable), just because the latter is more readable and
less breakable.  And const-ify where possible.

Back-patch to 9.3 where the nonportable code was added.

Andres Freund and Tom Lane

doc:  improve 9.4 release notes

Patch by Andres Freund

Ooops, I broke initdb with that last patch.

That's what I get for not fully retesting the final version of the patch.
The replace_allowed cross-check needs an additional special case for
bootstrapping.

Fix two ancient memory-leak bugs in relcache.c.

RelationCacheInsert() ignored the possibility that hash_search(HASH_ENTER)
might find a hashtable entry already present for the same OID.  However,
that can in fact occur during recursive relcache load scenarios.  When it
did happen, we overwrote the pointer to the pre-existing Relation, causing
a session-lifespan leakage of that entire structure.  As far as is known,
the pre-existing Relation would always have reference count zero by the
time we arrive back at the outer insertion, so add code that deletes the
pre-existing Relation if so.  If by some chance its refcount is positive,
elog a WARNING and allow the pre-existing Relation to be leaked as before.

Also, AttrDefaultFetch() was sloppy about leaking the cstring form of the
pg_attrdef.adbin value it's copying into the relcache structure.  This is
only a query-lifespan leakage, and normally not very significant, but it
adds up during CLOBBER_CACHE testing.

These bugs are of very ancient vintage, but I'll refrain from back-patching
since there's no evidence that these leaks amount to anything in ordinary
usage.

Make fallback implementation of pg_memory_barrier() work.

The fallback implementation involves acquiring and releasing a spinlock
variable that is otherwise unreferenced --- not even to the extent of
initializing it.  This accidentally fails to fail on platforms where
spinlocks should be initialized to zeroes, but elsewhere it results in
a "stuck spinlock" failure during startup.

I griped about this last July, and put in a hack that worked for gcc
on HPPA, but didn't get around to fixing the general case.  Per the
discussion back then, the best thing to do seems to be to initialize
dummy_spinlock in main.c.

Fix a bunch of functions that were declared static then defined not-static.

Per testing with a compiler that whines about this.

Fix unaligned accesses in DecodeUpdate().

The xl_heap_header_len structures in an XLOG_HEAP_UPDATE record aren't
necessarily aligned adequately.  The regular replay function for these
records is aware of that, but decode.c didn't get the memo.  I'm not
sure why the buildfarm failed to catch this; the test_decoding test
certainly blows up real good on my old HPPA box.

Also, I'm pretty sure that the address arithmetic was wrong for the
case of XLOG_HEAP_CONTAINS_OLD and not XLOG_HEAP_CONTAINS_NEW_TUPLE,
though this apparently can't happen when logical decoding is active.

Update README, we don't do post-recovery cleanup actions anymore.

transam/README explained how B-tree incomplete splits were tracked and
fixed after recovery, as an example of handling complex actions that need
multiple WAL records, but that's not how it works anymore. Explain the new
paradigm.

Make sure chr(int) can't create invalid UTF8 sequences.

Several years ago we changed chr(int) so that if the database encoding is
UTF8, it would interpret its argument as a Unicode code point and expand it
into the appropriate multibyte sequence.  However, we weren't sufficiently
careful about checking validity of the input.  According to RFC3629, UTF8
disallows code points above U+10FFFF (note that the predecessor standard
RFC2279 was more liberal).  Also, both versions of the UTF8 spec agree
that Unicode surrogate-pair codes should never appear in UTF8.  Because
our encoding validity checks follow RFC3629, our failure to enforce these
restrictions in chr() means it could be used to produce text strings that
will be rejected when the database is dumped and reloaded.  To ensure
consistency with the input functions, let's actually apply
pg_utf8_islegal() to the proposed output of chr().

Per discussion, this seems like too much of a behavioral change to
back-patch, but it's not too late to squeeze it into 9.4.

Suppress some more valgrind whining about btree_gist.

A couple of functions didn't bother to zero out pad bytes in datums that
would ultimately go to disk.  Harmless, but valgrind doesn't know that.

Fix a second cause of undersized pallocs for btree_gist indexes on macaddr.

gbt_macad_union also allocated 12-byte structs where we really need 16.

Per report from Andres Freund.  No back-patch since there's no current
risk of a real problem.

Fix valgrind warning for btree_gist indexes on macaddr.

The macaddr opclass stores two macaddr structs (each of size 6) in an
index column that's declared as being of type gbtreekey16, ie 16 bytes.
In the original coding this led to passing a palloc'd value of size 12
to the index insertion code, so that data would be fetched past the
end of the allocated value during index tuple construction.  This makes
valgrind unhappy.  In principle it could result in a SIGSEGV, though
with the current implementation of palloc there's no risk since
the 12-byte request size would be rounded up to 16 bytes anyway.

To fix, add a field to struct gbtree_ninfo showing the declared size of
the index datums, and use that in the palloc requests; and use palloc0
to be sure that any wasted bytes are cleanly initialized.

Per report from Andres Freund.  No back-patch since there's no current
risk of a real problem.

Add test case for logical decoding of prepared transactions.

Andres Freund

Fix test_decoding test case's check that slot has been dropped.

pg_stat_replication shows connected replication clients. The ddl test case
never has any replication clients connected, so querying pg_stat_replication
is pointless. To check that a slot has been dropped correctly, query
pg_replication_slots instead.

Andres Freund

Fix thinko in logical decoding of commit-prepared records.

The decoding of prepared transaction commits accidentally used the XID of
the transaction performing the COMMIT PREPARED, not the XID of the prepared
transaction. Before bb38fb0d43c8d that lead to those transactions not being
decoded, afterwards to a assertion failure.

Open output file before sleeping in pg_recvlogical.

Let's complain about e.g an invalid path or permission problem sooner rather
than later. Before this patch, we would only try to open the output file
after receiving the first decoded message from the server.

Initialize tsId and dbId fields in WAL record of COMMIT PREPARED.

Commit dd428c79 added dbId and tsId to the xl_xact_commit struct but missed
that prepared transaction commits reuse that struct. Fix that.

Because those fields were left unitialized, replaying a commit prepared WAL
record in a hot standby node would fail to remove the relcache init file.
That can lead to "could not open file" errors on the standby. Relcache init
file only needs to be removed when a system table/index is rewritten in the
transaction using two phase commit, so that should be rare in practice. In
HEAD, the incorrect dbId/tsId values are also used for filtering in logical
replication code, causing the transaction to always be filtered out.

Analysis and fix by Andres Freund. Backpatch to 9.0 where hot standby was
introduced.

Fix unportable setvbuf() usage in initdb.

In yesterday's commit 2dc4f011fd61501cce507be78c39a2677690d44b, I tried
to force buffering of stdout/stderr in initdb to be what it is by
default when the program is run interactively on Unix (since that's how
most manual testing is done).  This tripped over the fact that Windows
doesn't support _IOLBF mode.  We dealt with that a long time ago in
syslogger.c by falling back to unbuffered mode on Windows.  Export that
solution in port.h and use it in initdb.

Back-patch to 8.4, like the previous commit.

Fix whitespace

Fix a couple of bugs in pg_recvlogical output to stdout.

Don't close stdout on SIGHUP. Also, when a SIGHUP is received, close the
file immediately, rather than only after receiving some more data from
the server. Rename a variable, to avoid mentally dealing with double
negatives (not unsynced means synced).

Handle duplicate XIDs in txid_snapshot.

The proc array can contain duplicate XIDs, when a transaction is just being
prepared for two-phase commit. To cope, remove any duplicates in
txid_current_snapshot(). Also ignore duplicates in the input functions, so
that if e.g. you have an old pg_dump file that already contains duplicates,
it will be accepted.

Report and fix by Jan Wieck. Backpatch to all supported versions.

Fix race condition in preparing a transaction for two-phase commit.

To lock a prepared transaction's shared memory entry, we used to mark it
with the XID of the backend. When the XID was no longer active according
to the proc array, the entry was implicitly considered as not locked
anymore. However, when preparing a transaction, the backend's proc array
entry was cleared before transfering the locks (and some other state) to
the prepared transaction's dummy PGPROC entry, so there was a window where
another backend could finish the transaction before it was in fact fully
prepared.

To fix, rewrite the locking mechanism of global transaction entries. Instead
of an XID, just have simple locked-or-not flag in each entry (we store the
locking backend's backend id rather than a simple boolean, but that's just
for debugging purposes). The backend is responsible for explicitly unlocking
the entry, and to make sure that that happens, install a callback to unlock
it on abort or process exit.

Backpatch to all supported versions.

Misc message style and doc fixes.

Euler Taveira

Silence warnings about redefining popen on Mingw-w64.

Mingw-w64 headers map popen/pclose to _popen and _pclose, but we want to use
our popen wrapper rather than the Mingw-w64. #undef the Mingw's version.

doc: Clarify what files pg_basebackup omits from data directory

pg_ctl: Write error messages to stderr

In initdb, ensure stdout/stderr buffering behavior is what we expect.

Since this program may print to either stdout or stderr, the relative
ordering of its messages depends on the buffering behavior of those files.
Force stdout to be line-buffered and stderr to be unbuffered, ensuring
that the behavior will match standard Unix interactive behavior, even
when stdout and stderr are rerouted to a file.

Per complaint from Tomas Vondra.  The particular case he pointed out is
new in HEAD, but issues of the same sort could arise in any branch with
other error messages, so back-patch to all branches.

I'm unsure whether we might not want to do this in other client programs
as well.  For the moment, just fix initdb.

pg_update:  slight major version adjustment

Fix version check for pg_upgrade line type crosscheck.

Per buildfarm.

pg_upgrade:  error out on 'line' data type usage

The data type internal format changed in 9.4.  Also mention this in the
9.4 release notes.

Code review for recent changes in relcache.c.

rd_replidindex should be managed the same as rd_oidindex, and rd_keyattr
and rd_idattr should be managed like rd_indexattr.  Omissions in this area
meant that the bitmapsets computed for rd_keyattr and rd_idattr would be
leaked during any relcache flush, resulting in a slow but permanent leak in
CacheMemoryContext.  There was also a tiny probability of relcache entry
corruption if we ran out of memory at just the wrong point in
RelationGetIndexAttrBitmap.  Otherwise, the fields were not zeroed where
expected, which would not bother the code any AFAICS but could greatly
confuse anyone examining the relcache entry while debugging.

Also, create an API function RelationGetReplicaIndex rather than letting
non-relcache code be intimate with the mechanisms underlying caching of
that value (we won't even mention the memory leak there).

Also, fix a relcache flush hazard identified by Andres Freund:
RelationGetIndexAttrBitmap must not assume that rd_replidindex stays valid
across index_open.

The aspects of this involving rd_keyattr date back to 9.3, so back-patch
those changes.

doc:  fix 9.4 release notes typo

Report by Dean Rasheed

doc: fix typo in 9.4 release note comments

Patch by Sergey Muraviov

Make initdb throw error for bad locale values.

Historically we've printed a complaint for a bad locale setting, but then
fallen back to the environment default.  Per discussion, this is not such
a great idea, because rectifying an erroneous locale choice post-initdb
(perhaps long after data has been loaded) could be enormously expensive.
Better to complain and give the user a chance to double-check things.

The behavior was particularly bad if the bad setting came from environment
variables rather than a bogus command-line switch: in that case not only
was there a fallback to C/SQL_ASCII, but the printed complaint was quite
unhelpful.  It's hard to be entirely sure what variables setlocale looked
at, but we can at least give a hint where the problem might be.

Per a complaint from Tomas Vondra.

docs:  mention windows quoting change in 9.4 release notes

Report by Heikki Linnakangas

doc:  auto-updatable view adjustments for 9.4 release notes

Report by Dean Rasheed

docs:  9.4 release notes adjustments

Patch by Andres Freund, slight adjustments by me

Fix harmless access to uninitialized memory.

When cache invalidations arrive while ri_LoadConstraintInfo() is busy
filling a new cache entry, InvalidateConstraintCacheCallBack() compares
the - not yet initialized - oidHashValue field with the to-be-invalidated
hash value. To fix, check whether the entry is already marked as invalid.

Andres Freund

Initialize padding bytes in btree_gist varbit support.

The code expands a varbit gist leaf key to a node key by copying the bit
data twice in a varlen datum, as both the lower and upper key. The lower key
was expanded to INTALIGN size, but the padding bytes were not initialized.
That's a problem because when the lower/upper keys are compared, the padding
bytes are used compared too, when the values are otherwise equal. That could
lead to incorrect query results.

REINDEX is advised for any btree_gist indexes on bit or bit varying data
type, to fix any garbage padding bytes on disk.

Per Valgrind, reported by Andres Freund. Backpatch to all supported
versions.

Add Valgrind suppression for reorderbuffer padding bytes.

Andres Freund

docs:  use structfield instead of structname in 9.4 release notes

Where appropriate

doc: 9.4 release note adjustments

Report by Nicolas Barbier, Tatsuo Ishii, MauMau

Be more wary in choice of timezone names to test make_timestamptz with.

America/Metlakatla hasn't been in the IANA database all that long, so
some installations might not have it.  It does seem worthwhile to test
with a fractional-minute GMT offset, but we can get that from almost
any pre-1900 date; I chose Europe/Paris, whose LMT offset from Greenwich
should be pretty darn well established.

Also, assuming that Mars/Mons_Olympus will never be in the IANA database
seems less than future-proof, so let's use a more fanciful location for
the bad-zone-name check.

Per complaint from Christoph Berg.

Ignore config.pl and buildenv.pl in src/tools/msvc.

config.pl and buildenv.pl can be used to customize build settings when
using MSVC.  They should never get committed into the common source tree.

Back-patch to 9.0; it looks like the rules were different in 8.4.

Michael Paquier

Fix typo in test_shm_mq document.

Amit Langote

Free PQresult on error in pg_receivexlog.

The leak is fairly small and rare, but a leak nevertheless.

Per Coverity report. Backpatch to 9.2, where pg_receivexlog was added.
pg_basebackup shares the code, but it always exits on error, so there is
no real leak.

Stamp 9.4beta1.

Find postgresql.auto.conf in PGDATA even when postgresql.conf is elsewhere.

The original coding for ALTER SYSTEM made a fundamentally bogus assumption
that postgresql.auto.conf could be sought relative to the main config file
if we hadn't yet determined the value of data_directory.  This fails for
common arrangements with the config file elsewhere, as reported by
Christoph Berg.

The simplest fix is to not try to read postgresql.auto.conf until after
SelectConfigFiles has chosen (and locked down) the data_directory setting.

Because of the logic in ProcessConfigFile for handling resetting of GUCs
that've been removed from the config file, we cannot easily read the main
and auto config files separately; so this patch adopts a brute force
approach of reading the main config file twice during postmaster startup.
That's a tad ugly, but the actual time cost is likely to be negligible,
and there's no time for a more invasive redesign before beta.

With this patch, any attempt to set data_directory via ALTER SYSTEM
will be silently ignored.  It would probably be better to throw an
error, but that can be dealt with later.  This bug, however, would
prevent any testing of ALTER SYSTEM by a significant fraction of the
userbase, so it seems important to get it fixed before beta.

Rename jsonb_hash_ops to jsonb_path_ops.

There's no longer much pressure to switch the default GIN opclass for
jsonb, but there was still some unhappiness with the name "jsonb_hash_ops",
since hashing is no longer a distinguishing property of that opclass,
and anyway it seems like a relatively minor detail.  At the suggestion of
Heikki Linnakangas, we'll use "jsonb_path_ops" instead; that captures the
important characteristic that each index entry depends on the entire path
from the document root to the indexed value.

Also add a user-facing explanation of the implementation properties of
these two opclasses.

Translation updates

docs:  Mark 9.4 release notes as current as of today

Rename min_recovery_apply_delay to recovery_min_apply_delay.

Per discussion, this seems like a more consistent choice of name.

Fabrízio de Royes Mello, after a suggestion by Peter Eisentraut;
some additional documentation wordsmithing by me

More work on the JSON/JSONB user documentation.

Document existence operator adequately; fix obsolete claim that no
Unicode-escape semantic checks happen on input (it's still true for
json, but not for jsonb); improve examples; assorted wordsmithing.

Fix bug in lossy-page handling in GIN

When returning rows from a bitmap, as done with partial match queries, we
would get stuck in an infinite loop if the bitmap contained a lossy page
reference.

This bug is new in master, it was introduced by the patch to allow skipping
items refuted by other entries in GIN scans.

Report and fix by Alexander Korotkov

Accept tcl 8.6 in configure's probe for tclsh.

Usually the search would find plain "tclsh" without any trouble,
but some installations might only have the version-numbered flavor
of that program.

No compatibility problems have been reported with 8.6, so we might
as well back-patch this to all active branches.

Christoph Berg

Update config.guess and config.sub

Fix bogus documentation of json_object_agg().

It takes two arguments, not one.

Fix broken allocation logic in recently-rewritten jsonb_util.c.

reserveFromBuffer() failed to consider the possibility that it needs to
more-than-double the current buffer size.  Beyond that, it seems likely
that we'd someday need to worry about integer overflow of the buffer
length variable.  Rather than reinvent the logic that's already been
debugged in stringinfo.c, let's go back to using that logic.  We can
still have the same targeted API, but we'll rely on stringinfo.c to
manage reallocation.

Per report from Alexander Korotkov.

Improve user-facing JSON documentation.

I started out with the intention of just fixing the info about the jsonb
operator classes, but soon found myself copy-editing most of the JSON
material.  Hopefully it's more readable now.

Get rid of bogus dependency on typcategory in to_json() and friends.

These functions were relying on typcategory to identify arrays and
composites, which is not reliable and not the normal way to do it.
Using typcategory to identify boolean, numeric types, and json itself is
also pretty questionable, though the code in those cases didn't seem to be
at risk of anything worse than wrong output.  Instead, use the standard
lsyscache functions to identify arrays and composites, and rely on a direct
check of the type OID for the other cases.

In HEAD, also be sure to look through domains so that a domain is treated
the same as its base type for conversions to JSON.  However, this is a
small behavioral change; given the lack of field complaints, we won't
back-patch it.

In passing, refactor so that there's only one copy of the code that decides
which conversion strategy to apply, not multiple copies that could (and
have) gotten out of sync.

Code review for logical decoding patch.

Post-commit review identified a number of places where addition was
used instead of multiplication or memory wasn't zeroed where it should
have been.  This commit also fixes one case where a structure member
was mis-initialized, and moves another memory allocation closer to
the place where the allocated storage is used for clarity.

Andres Freund

Remove overeager assertion in logical_heap_begin_rewrite.

It's legal to configure wal_level=logical and max_replication_slots=0
simultaneously.

Andres Freund

Teach add_json() that jsonb is of TYPCATEGORY_JSON.

This code really needs to be refactored so that there aren't so many copies
that can diverge.  Not to mention that this whole approach is probably
wrong.  But for the moment I'll just stick my finger in the dike.
Per report from Michael Paquier.

Fix typcategory labeling of jsonb.

Dunno who had the cute idea of labeling jsonb as typcategory 'C',
but it is not a composite type.  Label it 'U', since that's what
json is using.

More jsonb cleanup.

Fix JSONB_MAX_ELEMS and JSONB_MAX_PAIRS macros to use CB_MASK in the
calculation. JENTRY_POSMASK happens to have the same value at the moment,
but that's just coincidental.

Refactor jsonb iterator functions, for readability.

Get rid of the JENTRY_ISFIRST flag. Whenever we handle JEntrys, we have
access to the whole array and have enough context information to know
which entry is the first. This frees up one bit in the JEntry header for
future use. While we're at it, shuffle the JEntry bits so that boolean
true and false go together, for aesthetic reasons.

Bump catalog version as this changes the on-disk format slightly.

Improve key representation for GIN jsonb_ops, and fix existence-search bug.

Change the key representation so that values that would exceed 127 bytes
are hashed into short strings, and so that the original JSON datatype of
each value is recorded in the index.  The hashing rule eliminates the major
objection to having this opclass be the default for jsonb, namely that it
could fail for plausible input data (due to GIN's restrictions on maximum
key length).  Preserving datatype information doesn't really buy us much
right now, but it requires no extra space compared to the previous way,
and it might be useful later.

Also, change the consistency-checking functions to request recheck for
exists (jsonb ? text) and related operators.  The original analysis that
this is an exactly checkable query was incorrect, since the index does
not preserve information about whether a key appears at top level in
the indexed JSON object.  Add a test case demonstrating the problem.

Make some other, mostly cosmetic improvements to the code in jsonb_gin.c
as well.

catversion bump due to on-disk data format change in jsonb_ops indexes.

Minor cleanup of jsonb_util.c

Move the functions around to group related functions together. Remove
binequal argument from lengthCompareJsonbStringValue, moving that
responsibility to lengthCompareJsonbPair. Fix typo in comment.

Avoid some pnstrdup()s when constructing jsonb

This speeds up text to jsonb parsing and hstore to jsonb conversions
somewhat.

Fix missing dependencies in ecpg's test Makefiles.

Ensure that ecpg preprocessor output files are rebuilt when re-testing
after a change in the ecpg preprocessor itself, or a change in any of
several include files that get copied verbatim into the output files.
The lack of these dependencies was what created problems for Kevin Grittner
after the recent pgindent run.  There's no way for --enable-depend to
discover these dependencies automatically, so we've gotta put them into
the Makefiles by hand.

While at it, reduce the amount of duplication in the ecpg invocations.

Document permissions needed for pg_database_size and pg_tablespace_size.

Back in 8.3, we installed permissions checks in these functions (see
commits 8bc225e7990a and cc26599b7206).  But we forgot to document that
anywhere in the user-facing docs; it did get mentioned in the 8.3 release
notes, but nobody's looking at that any more.  Per gripe from Suya Huang.

Increase the default value of effective_cache_size to 4GB.

Per discussion, the old value of 128MB is ridiculously small on modern
machines; in fact, it's not even any larger than the default value of
shared_buffers, which it certainly should be.  Increase to 4GB, which
is unlikely to be any worse than the old default for anyone, and should
be noticeably better for most.  Eventually we might have an autotuning
scheme for this setting, but the recent attempt crashed and burned,
so for now just do this.