The WAL segment size is something that can be customized at initialization
time in v11, and was previously decided at compilation time. This makes the
module able to work with a default segment size of 16MB. In order to
support more sizes, the segment size needs to be passed as an argument.

Before server parameters are loaded, enforce redirection of log messages
to stderr, using the same method as what syslogger.c and postmaster.c do.
Also avoid duplicate entries to server logs, and be careful about messages
that are too verbose.

This makes the whole module more consistent with its interface to the
user.

The data is in binary format.

This was referring to COPY, which was used at some point. At the same
time, fix an incorrect error code.

This is useful if combined with the function to get a full data chunk
from the archives. At the same time regression tests are refactored
so as the extension wal_utils is created only once as initialization
for all the other tests.

This can be satisfied only if caller has not provided a history file.
Regression tests are added as well.

Instead of some weird COPY and string aggregates, just hardcode the
history file contents, this is enough to validate the code.

This is useful, using a history file to track a set of WAL segments
needed. This takes care of timeline jumps, a bit more needs to be
done for the case where the target and origin timelines are the same
by using a fake history entry as history.

This function is useful if combined with pg_read_file(), pointing to
the history file of a given timeline.

Upstream commit 2cd7084 has removed direct access to attribute data from
TupleDesc and replaces them by a macro, so apply the same change here.

This flag will be set to true only once the data of the WAL receiver can
be displayed to the user, so return NULL if this is not the case yet in
the function showing the WAL receiver status. In Postgres 10, there is
already an in-core function doing this work, perhaps I should just plug in
this module into that, or simply remove it...

The spin lock related to the WAL receiver was taken for a too long time,
in code paths that invoked as well catalog lookups. Reduce the acquisition
to a minimum amount of time, so as nothing blows up on an overly-busy system.

Spotted by Peter Geoghegan.

When checking for the PID of active backends, make sure that those lookups
are protected by ProcArrayLock. At the same time fix a one-off bug in the
proc array lookup, which would lead to looking at an unwanted memory area.

Both issues have been pointed out by Peter Geoghegan offlist.

No need to maintain twice the same code.

Upstream commit 18ce3a4a has changed the shape of the utility hook,
so adapt to it.

Those routines should never return and exit properly, so mark them
as such as a saity measure.

Those modules will not be able to work with older versions than
Postgres 10 if left as-is, so let's keep life simple.

Header for gettimeofday() has gone missing.

Upstream commit 2113ac4c has removed bgw_main field from the bgworker
registration worker, so adapt all the modules to this new rule.

I have mislead the Unicode code with the real hexadecimal values, leading
to a bunch of errors with decompositions and recompositions.

The following things are adjusted:
- Ignore correctly characters from the exclusion tables.
- Improve variable name consistency.
- Simplify readability of Hangul character calculation.

This is still experimental as the recomposition phase is still printing
corrupted data but the algorithm looks correct.

The main table tracks the length of each decomposition, which is then
used with each character code to look at the decomposition set on a
set of tables divided by decomposition size. This gets the binary size
from 2.4MB to 120kB, or 20 times less. I am not sure if I could get
that further down, no space is wasted now.

Characters with a class of 0 and no decompositions don't really need
to be in the table and any abscence of such characters in the table
would mean that they have the following limitations. This reduces the
size of the table from 2.4MB to 570kB, which is already a good win.

The Unicode documentation is rather specific on the matter with that:
http://unicode.org/reports/tr15/tr15-18.html#Hangul

A couple of utilities are added at the same time to manipulate easily
UTF-8 strings as arrays of integers:
- UTF-8 string to integer array conversion.
- integer array to UTF-8 string conversion.
- Generation of header file from UnicodeData.txt that Postgres can
refer to.
- Set returning function to view at SQL level the conversion table.
- SASLprep function.