Use a hash table to store current sequence values.

This speeds up nextval() and currval(), when you touch a lot of different
sequences in the same backend.

David Rowley
Fix bogus hash table creation.

Andres Freund
doc: Restore proper alphabetical order.

Colin 't Hart
Fix buffer overrun in isolation test program.

Commit 061b88c732952c59741374806e1e41c1ec845d50 saved argv0 to a
global buffer without ensuring that it was zero terminated,
allowing references to it to overrun the buffer and access other
memory.  This probably would not have presented any security risk,
but could have resulted in very confusing failures if the path to
the executable was very long.

Reported by David Rowley
Minor comment corrections for sequence hashtable patch.

There were enough typos in the comments to annoy me ...
Prevent leakage of cached plans and execution trees in plpgsql DO blocks.

plpgsql likes to cache query plans and simple-expression execution state
trees across calls.  This is a considerable win for multiple executions
of the same function.  However, it's useless for DO blocks, since by
definition those are executed only once and discarded.  Nonetheless,
we were allowing a DO block's expression execution trees to survive
until end of transaction, resulting in a significant intra-transaction
memory leak, as reported by Yeb Havinga.  Worse, if the DO block exited
with an error, the compiled form of the block's code was leaked till
end of session --- along with subsidiary plancache entries.

To fix, make DO blocks keep their expression execution trees in a private
EState that's deleted at exit from the block, and add a PG_TRY block
to plpgsql_inline_handler to make sure that memory cleanup happens
even on error exits.  Also add a regression test covering error handling
in a DO block, because my first try at this broke that.  (The test is
not meant to prove that we don't leak memory anymore, though it could
be used for that with a much larger loop count.)

Ideally we'd back-patch this into all versions supporting DO blocks;
but the patch needs to add a field to struct PLpgSQL_execstate, and that
would break ABI compatibility for third-party plugins such as the plpgsql
debugger.  Given the small number of complaints so far, fixing this in
HEAD only seems like an acceptable choice.
SSL: GUC option to prefer server cipher order

By default OpenSSL (and SSL/TLS in general) lets client cipher
order take priority.  This is OK for browsers where the ciphers
were tuned, but few Postgres client libraries make cipher order
configurable.  So it makes sense to make cipher order in
postgresql.conf take priority over client defaults.

This patch adds setting 'ssl_prefer_server_ciphers' which can be
turned on so that server cipher order is preferred.

The setting SSL_OP_CIPHER_SERVER_PREFERENCE appeared in
OpenSSL 0.9.7 (31 Dec 2002), not sure if #ifdef is required
for conditional compilation.
SSL: Support ECDH key excange.

This sets up ECDH key exchange, when compiling against OpenSSL
that supports EC.  Then ECDHE-RSA and ECDHE-ECDSA ciphersuites
can be used for SSL connections.  Latter one means that EC keys
are now usable.

The reason for EC key exchange is that it's faster than DHE
and it allows to go to higher security levels where RSA will
be horribly slow.

Quick test with single-threaded client connecting repeatedly
to server on same machine, then closes connection.  Measured
is connections-per-second.

  Key             DHE     ECDHE
  RSA-1024        177.5   278.1   (x 1.56)
  RSA-2048        140.5   191.1   (x 1.36)
  RSA-4096        59.5    67.3    (x 1.13)
  ECDSA-256               280.7   (~ RSA-3072)
  ECDSA-384               128.9   (~ RSA-7680)

There is also new GUC option - ssl_ecdh_curve - that specifies
curve name used for ECDH.  It defaults to "prime256v1", which
is the most common curve in use in HTTPS.  According to NIST
should be securitywise similar to ~3072 bit RSA/DH.
(http://www.keylength.com / NIST Recommendations).

Other commonly-implemented curves are secp384r1 and secp521r1
(OpenSSL names).  The rest are not recommended as EC curves
needed to be exchanged by name and need to be explicitly
supprted by both client and server.  TLS does have free-form
curve exchange, but few client libraries implement that,
at least OpenSSL does not.

Full list can be seen with "openssl ecparam -list_curves".

It does not tune ECDH curve with key size automatically,
like DHE does.  The reason is the curve naming situation.
SSL: Better default ciphersuite

Change the default ciphersuite to

	HIGH:!aNULL

instead of old

	DEFAULT:!LOW:!EXP:!MD5:@STRENGTH

[ Note - DEFAULT is documented as shortcut for "ALL:!aNULL:!eNULL" ]

Main goal is to leave ciphersuite maintenance to OpenSSL guys
and give correct impression to Postgres admins what it is about.

New value will remove all suites with RC4 and SEED from ciphersuite list.
If OpenSSL is compiled with support for SSL2 it will include following
suite: DES-CBC3-MD5 (3DES + HMAC-MD5), usable only for SSL2 connections.

Tested with OpenSSL 0.9.7 - 1.0.2, using "openssl ciphers -v ..." command.

Values used
-----------

HIGH:
  Contains only secure and well-researched algorithms.

!aNULL
  Needed to disable suites that do not authenticate server.
  DEFAULT includes !aNULL by default.

Values not used
---------------

!MD5
  This affects only one suite: DES-CBC3-MD5, which is available only
  for SSL2 connections.  So it would only pollute the default value.

@STRENGTH
  The HIGH/DEFAULT suite lists are already sorted by humans,
  it's unlikely that mechanical sort would improve things.
  Also the existense of this value in old list is rather
  dubious, as server cipher order was never respected anyway.