Allow wal_log_hints to be changed without restart

Hi hackers,

As f19c0ecca introduced online enabling and disabling of data checksums, I
think that it would make sense to do the same for wal_log_hints. Indeed, it
can be used to test how much extra WAL-logging would occur if your database had
data checksums enabled. Since 04bec894a04, data checksums is on by default, but
it could still be set to false due to user choice or after an upgrade.

In that case, I think that it sounds weird to ask for a restart to set wal_log_hints
to test the impact of data checksums that does not require a restart anymore. I
think that the entire flow (test + enable or disable) should be done without a
restart (not just a portion of it).

So, PFA a patch to $SUBJECT.

Basically, it:

- Changes wal_log_hints from PGC_POSTMASTER to PGC_SIGHUP.
- uses the same pattern as full_page_writes as it does not need the complexity
of procsignal barriers that has been used in f19c0ecca. Indeed, it's not a multi
state transition and no all backends must agree simultaneously.

The key concern is that when turning wal_log_hints OFF, no backend should stop
WAL-logging hint bit updates before the parameter change is itself WAL-logged.
Simply propagating the GUC via SIGHUP would leave a window where a backend could
acknowledge the change before the WAL record is written.

To address this, the patch introduces a shared memory flag (XLogCtl->walLogHints)
that serves as the authoritative value read by all backends via XLogHintBitIsNeeded().

Only the checkpointer writes this flag, using the same ordering pattern as
UpdateFullPageWrites():

- When enabling: set the shared flag to true first, then WAL-log the parameter
change. Backends immediately start WAL-logging hints and the extra WAL before the
record is harmless.

- When disabling: WAL-log the parameter change first, then set the
shared flag to false.

As in commit 3b682df3260 (which added the same pattern to UpdateFullPageWrites()),
a critical section is used as extra protection to ensure consistency between the
flag and the WAL record, even though the ordering makes both failure directions
harmless (extra WAL-logging).

As Michael noted in the original thread [1], pg_rewind only needs wal_log_hints
to be on "when WAL forked": it only scans WAL from the fork point forward.
Toggling wal_log_hints off and back on before a timeline divergence does not
create a gap, because hint-bit changes from before the fork are irrelevant to
pg_rewind. The pg_rewind check on ControlFile->wal_log_hints (which reflects
the current state at rewind time) remains sufficient.

[1] https://postgr.es/m/CAB7nPqSXYs4Jg-KJMy8xiM4sTqkgKvHyDrCoojhXzRSKiW57+g@mail.gmail.com

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com