MySQL 8.0.30
Source Code Documentation
log_sink_buffer.cc File Reference

This file contains. More...

Classes

struct  log_line_buffer
 

Functions

static bool log_line_duplicate (log_line *dst, log_line *src)
 Duplicate a log-event. More...
 
int log_sink_buffer (void *instance, log_line *ll)
 services: log sinks: buffered logging More...
 
void log_sink_buffer_flush (enum log_sink_buffer_flush_mode mode)
 Release all buffered log-events (discard_error_log_messages()), optionally after running them through the error log stack first (flush_error_log_messages()). More...
 

Variables

bool log_builtins_inited
 Subsystem initialized and ready to use? More...
 
mysql_mutex_t THR_LOCK_log_buffered
 Make sure only one instance of the buffered "writer" runs at a time. More...
 
static log_line_bufferlog_line_buffer_start = nullptr
 Pointer to the first element in the list of buffered log messages. More...
 
static log_line_buffer ** log_line_buffer_tail = &log_line_buffer_start
 Where to write the pointer to the newly-created tail-element of the list. More...
 
static ulonglong log_sink_buffer_latest_buffered = 0
 Timestamp of the last event we put into the error-log buffer during buffered mode (while starting up). More...
 

Detailed Description

This file contains.

a) the log-sink that buffers errors logged during start-up so they can be flushed once all configured log-components have become available;

b) the functions for querying and setting the phase the server is in with regard to logging (buffering, normal operation, and so forth);

c) the functions for flushing the buffered information (to force writing out this information in cases of early shutdowns and so on).

Function Documentation

◆ log_line_duplicate()

static bool log_line_duplicate ( log_line dst,
log_line src 
)
static

Duplicate a log-event.

This is a deep copy where the items (key/value pairs) have their own allocated memory separate from that in the source item.

Parameters
dstlog_line that will hold the copy
srclog_line we copy from
Return values
falseon success
trueif out of memory

◆ log_sink_buffer()

int log_sink_buffer ( void *  instance,
log_line ll 
)

services: log sinks: buffered logging

Write a log-event to the buffer sink.

During start-up, we buffer log-info until a) we have basic info for the built-in logger (what file to log to, verbosity, and so on), and b) advanced info (any logging components to load, any configuration for them, etc.).

As a failsafe, if start-up takes very, very long, and a time-out is reached before reaching b) and we actually have something worth reporting (e.g. errors, as opposed to info), we try to keep the user informed by using the basic logger configured in a), while going on buffering all info and flushing it to any advanced loggers when b) is reached.

1) This function checks and, if needed, updates the time-out, and calls the flush functions as needed. It is internal to the logger and should not be called from elsewhere.

2) Function will save log-event (if given) for later filtering and output.

3) Function acquires/releases THR_LOCK_log_buffered if initialized.

Parameters
instanceinstance handle Not currently used in this writer; if this changes later, keep in mind that nullptr will be passed if this is called before the structured logger's locks are initialized, so that must remain a valid argument!
llThe log line to write, or nullptr to not add a new logline, but to just check whether the time-out has been reached and if so, flush as needed.
Return values
-1can not add event to buffer (OOM?)
>0number of added fields

< log-line buffer

◆ log_sink_buffer_flush()

void log_sink_buffer_flush ( enum log_sink_buffer_flush_mode  mode)

Release all buffered log-events (discard_error_log_messages()), optionally after running them through the error log stack first (flush_error_log_messages()).

Safe to call repeatedly (though subsequent calls will only output anything if further events occurred after the previous flush).

Parameters
modeLOG_BUFFER_DISCARD_ONLY (to just throw away the buffered events), or LOG_BUFFER_PROCESS_AND_DISCARD to filter/print them first

Variable Documentation

◆ log_builtins_inited

bool log_builtins_inited
extern

Subsystem initialized and ready to use?

◆ log_line_buffer_start

log_line_buffer* log_line_buffer_start = nullptr
static

Pointer to the first element in the list of buffered log messages.

◆ log_line_buffer_tail

log_line_buffer** log_line_buffer_tail = &log_line_buffer_start
static

Where to write the pointer to the newly-created tail-element of the list.

◆ log_sink_buffer_latest_buffered

ulonglong log_sink_buffer_latest_buffered = 0
static

Timestamp of the last event we put into the error-log buffer during buffered mode (while starting up).

New items must receive a LOG_ITEM_LOG_BUFFERED timestamp greater than this.

◆ THR_LOCK_log_buffered

mysql_mutex_t THR_LOCK_log_buffered

Make sure only one instance of the buffered "writer" runs at a time.

In normal operation, the log-event will be created dynamically, then it will be fed through the pipeline, and then it will be released. Since the event is allocated in the caller, we can be sure it won't go away wholesale during processing, and since the event is local to the caller, no other thread will tangle with it. It is therefore safe in those cases not to wrap a lock around the event. (The log-pipeline will still grab a shared lock, THR_LOCK_log_stack, to protect the pipeline (not the event) and the log-services cache from being changed while the pipeline is being applied. Likewise, log-services may protect their resources (file-writers will usually take a lock to serialize their writes; the built-in filter will take a lock on its rule-set as that is shared between concurrent threads running the filter, and so on). None of these are intended to protect the event itself though.

In buffered mode on the other hand, we copy each log-event (the original of which, see above, is owned by the caller and local to the thread, and therefore safe without locking) to a global buffer / backlog. As this backlog can be added to by all threads, it must be protected by a lock (once we have fully initialized the subsystem with log_builtins_init() and support multi-threaded mode anyway, as indicated by log_builtins_inited being true, see below). This is that lock.