Preset Options
- The following parameters
are read-only, and are determined
- when
PostgreSQL is compiled or when it is
- installed. As such, they have been excluded from the sample
+ The following parameters
are read-only.
+ As such, they have been excluded from the sample
postgresql.conf file. These options report
various aspects of
PostgreSQL behavior
that might be of interest to certain applications, particularly
administrative front-ends.
+ Most of them are determined when
PostgreSQL
+ is compiled or when it is installed.
- On Unix systems this parameter reports the permissions of the data
- directory defined by () at startup.
+ On Unix systems this parameter reports the permissions the data
+ directory (defined by )
+ had at server startup.
(On Microsoft Windows this parameter will always display
- 0700). See
+ 0700.) See
for more information.
+
+ in_hot_standby (boolean)
+
+
in_hot_standby configuration parameter
+
+
+
+ Reports whether the server is currently in hot standby mode. When
+ this is on, all transactions are forced to be
+ read-only. Within a session, this can change only if the server is
+ promoted to be primary. See for more
+ information.
+
+
+
+
lc_collate (string)
- Users will be able to tell whether their session is read-only by
- issuing SHOW transaction_read_only. In addition, a set of
+ Users can determine whether hot standby is currently active for their
+ session by issuing SHOW in_hot_standby.
+ (In server versions before 14, the in_hot_standby
+ parameter did not exist; a workable substitute method for older servers
+ is SHOW transaction_read_only.) In addition, a set of
functions () allow users to
access information about the standby server. These allow you to write
programs that are aware of the current state of the database. These
static const char *show_unix_socket_permissions(void);
static const char *show_log_file_mode(void);
static const char *show_data_directory_mode(void);
+static const char *show_in_hot_standby(void);
static bool check_backtrace_functions(char **newval, void **extra, GucSource source);
static void assign_backtrace_functions(const char *newval, void *extra);
static bool check_recovery_target_timeline(char **newval, void **extra, GucSource source);
static bool data_checksums;
static bool integer_datetimes;
static bool assert_enabled;
+static bool in_hot_standby;
static char *recovery_target_timeline_string;
static char *recovery_target_string;
static char *recovery_target_xid_string;
NULL, NULL, NULL
},
+ {
+ {"in_hot_standby", PGC_INTERNAL, PRESET_OPTIONS,
+ gettext_noop("Shows whether hot standby is currently active."),
+ NULL,
+ GUC_REPORT | GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+ },
+ &in_hot_standby,
+ false,
+ NULL, NULL, show_in_hot_standby
+ },
+
{
{"allow_system_table_mods", PGC_SUSET, DEVELOPER_OPTIONS,
gettext_noop("Allows modifications of the structure of system tables."),
reporting_enabled = true;
+ /*
+ * Hack for in_hot_standby: initialize with the value we're about to send.
+ * (This could be out of date by the time we actually send it, in which
+ * case the next ReportChangedGUCOptions call will send a duplicate
+ * report.)
+ */
+ in_hot_standby = RecoveryInProgress();
+
/* Transmit initial values of interesting variables */
for (i = 0; i < num_guc_variables; i++)
{
if (!reporting_enabled)
return;
+ /*
+ * Since in_hot_standby isn't actually changed by normal GUC actions, we
+ * need a hack to check whether a new value needs to be reported to the
+ * client. For speed, we rely on the assumption that it can never
+ * transition from false to true.
+ */
+ if (in_hot_standby && !RecoveryInProgress())
+ {
+ struct config_generic *record;
+
+ record = find_option("in_hot_standby", false, ERROR);
+ Assert(record != NULL);
+ record->status |= GUC_NEEDS_REPORT;
+ report_needed = true;
+ in_hot_standby = false;
+ }
+
/* Quick exit if no values have been changed */
if (!report_needed)
return;
return buf;
}
+static const char *
+show_in_hot_standby(void)
+{
+ /*
+ * We display the actual state based on shared memory, so that this GUC
+ * reports up-to-date state if examined intra-query. The underlying
+ * variable in_hot_standby changes only when we transmit a new value to
+ * the client.
+ */
+ return RecoveryInProgress() ? "on" : "off";
+}
+
/*
* We split the input string, where commas separate function names
* and certain whitespace chars are ignored, into a \0-separated (and