Performance Schema Miscellaneous Tables •A log sink can write new error events to the  error_log  table as they occur. •A log sink can provide a parser for extraction of previously written error messages. This enables a server instance to read messages written to an error log file by the previous instance and store them in the  error_log  table. Messages written during shutdown by the previous instance may be useful for diagnosing why shutdown occurred. •At startup, the server examines the  log_error_services  value and chooses from it the leftmost log sink that satisfies these conditions: •A sink that supports the  error_log  table and provides a parser. •If none, a sink that supports the  error_log  table but provides no parser. Currently, the traditional-format  log_sink_internal  and JSON-format  log_sink_json  sinks support writing new events to the  error_log  table and provide a parser for reading previously written error log files. The  log_error_services  system variable controls which log components to enable for error logging. Its value is a pipeline of log filter and log sink components to be executed in left-to-right order when error events occur. The  log_error_services  value pertains to populating the  error_log  table as follows: If no log sink satisfies those conditions, the  error_log  table remains empty. Otherwise, if the sink provides a parser and log configuration enables a previously written error log file to be found, the server uses the sink parser to read the last part of the file and writes the old events it contains to the table. The sink then writes new error events to the table as they occur. •At runtime, if the value of  log_error_services  changes, the server again examines it, this time looking for the leftmost enabled log sink that supports the  error_log  table, resgardless of whether it provides a parser. If no such log sink exists, no additional error events are written to the  error_log  table. Otherwise, the newly configured sink writes new error events to the table as they occur. Any configuration that affects output written to the error log affects  error_log  table contents. This includes settings such as those for verbosity, message suppression, and message filtering. It also applies to information read at startup from a previous log file. For example, messages not written during a previous server instance configured with low verbosity do not become available if the file is read by a current instance configured with higher verbosity. The  error_log  table is a view on a fixed-size, in-memory ring buffer, with old events automatically discarded as necessary to make room for new ones. As shown in the following table, several status variables provide information about ongoing  error_log  operation. Status Variable Meaning Error_log_buffered_bytes Bytes used in table Error_log_buffered_events Events present in table Error_log_expired_events Events discarded from table Error_log_latest_write Time of last write to table 27.12.21.2 The host_cache Table The MySQL server maintains an in-memory host cache that contains client host name and IP address information and is used to avoid Domain Name System (DNS) lookups. The  host_cache  table exposes the contents of this cache. The  host_cache_size  system variable controls the size of the host cache, 5080