From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: Improve handling of parameter differences in physical replicatio |
Date: | 2020-03-30 07:58:54 |
Message-ID: | E1jIpJu-0007Ql-CL@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Improve handling of parameter differences in physical replication
When certain parameters are changed on a physical replication primary,
this is communicated to standbys using the XLOG_PARAMETER_CHANGE WAL
record. The standby then checks whether its own settings are at least
as big as the ones on the primary. If not, the standby shuts down
with a fatal error.
The correspondence of settings between primary and standby is required
because those settings influence certain shared memory sizings that
are required for processing WAL records that the primary might send.
For example, if the primary sends a prepared transaction, the standby
must have had max_prepared_transaction set appropriately or it won't
be able to process those WAL records.
However, fatally shutting down the standby immediately upon receipt of
the parameter change record might be a bit of an overreaction. The
resources related to those settings are not required immediately at
that point, and might never be required if the activity on the primary
does not exhaust all those resources. If we just let the standby roll
on with recovery, it will eventually produce an appropriate error when
those resources are used.
So this patch relaxes this a bit. Upon receipt of
XLOG_PARAMETER_CHANGE, we still check the settings but only issue a
warning and set a global flag if there is a problem. Then when we
actually hit the resource issue and the flag was set, we issue another
warning message with relevant information. At that point we pause
recovery, so a hot standby remains usable. We also repeat the last
warning message once a minute so it is harder to miss or ignore.
Reviewed-by: Sergei Kornilov <sk(at)zsrv(dot)org>
Reviewed-by: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>
Reviewed-by: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Discussion: https://www.postgresql.org/message-id/flat/4ad69a4c-cc9b-0dfe-0352-8b1b0cd36c7b(at)2ndquadrant(dot)com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/246f136e76ecd26844840f2b2057e2c87ec9868d
Modified Files
--------------
doc/src/sgml/high-availability.sgml | 48 +++++++++++++++++------
src/backend/access/transam/twophase.c | 3 ++
src/backend/access/transam/xlog.c | 74 ++++++++++++++++++++++++++++++-----
src/backend/storage/ipc/procarray.c | 9 ++++-
src/backend/storage/lmgr/lock.c | 10 +++++
src/include/access/xlog.h | 1 +
6 files changed, 122 insertions(+), 23 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2020-03-30 08:37:03 | pgsql: Report waiting via PS while recovery is waiting for buffer pin i |
Previous Message | Peter Eisentraut | 2020-03-30 07:00:19 | pgsql: Add new part SQL/MDA to information_schema.sql_parts |
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2020-03-30 08:00:05 | Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch) |
Previous Message | Michael Paquier | 2020-03-30 07:57:50 | Re: Can we get rid of GetLocaleInfoEx() yet? |