Fixups for
17974ec259: Some messages were missed (and some were new
since the patch was originally proposed), and there was a typo
introduced.
{
ereport(isServerStart ? FATAL : LOG,
/*- translator: first %s is a GUC option name, second %s is its value */
- (errmsg("%s setting \"%s\" not supported by this build",
+ (errmsg("\"%s\" setting \"%s\" not supported by this build",
"ssl_max_protocol_version",
GetConfigOption("ssl_max_protocol_version",
false, false))));
"Up to %d background workers can be registered with the current settings.",
max_worker_processes,
max_worker_processes),
- errhint("Consider increasing the configuration parameter max_worker_processes.")));
+ errhint("Consider increasing the configuration parameter \"max_worker_processes\".")));
return;
}
*/
ereport(LOG,
(errmsg("restarting archiver process because value of "
- "archive_library was changed")));
+ "\"archive_library\" was changed")));
proc_exit(0);
}
if (wal_level < WAL_LEVEL_LOGICAL)
ereport(ERROR,
errcode(ERRCODE_INVALID_PARAMETER_VALUE),
- errmsg("slot synchronization requires wal_level >= \"logical\""));
+ errmsg("slot synchronization requires \"wal_level\" >= \"logical\""));
/*
* A physical replication slot(primary_slot_name) is required on the
gettext_noop("Continues processing past damaged page headers."),
gettext_noop("Detection of a damaged page header normally causes PostgreSQL to "
"report an error, aborting the current transaction. Setting "
- "\"zero_damaged_page\" to true causes the system to instead report a "
+ "\"zero_damaged_pages\" to true causes the system to instead report a "
"warning, zero out the damaged page, and continue processing. This "
"behavior will destroy data, namely all the rows on the damaged page."),
GUC_NOT_IN_SAMPLE