The pg_stat_monitor_errors view was created in order to help inspecting
internal errors that may occur in pg_stat_monitor module itself, it
contains the error message, its severity, the last time the error occurred
and the number of times that any given error ocurred.
Implementation details:
- A new lwlock was added to the pgssSharedState structure in order to
control access to the errors hash table.
- Increased RequestNamedLWLockTranche() no. of locks requested to 2.
- The function GetNamedLWLockTranche() returns an array of locks, we
use the first lock for controlling access to the usual buckets hash
table, and the second one to control access to the errors hash table.
- During module initialization (_PG_init) we increased the amount of
shared memory space requested to include space to the new errors hash
table: RequestAddinShmemSpace(... + pgsm_errors_size())
- The implementation in pgsm_errors.c simple uses a hash table to track
error messages, the message is also used as the key.
There were couple issues to handle, the main one was that our log hook
(pgsm_emit_log_hook) was being called after the shared memory hook
completed (pgss_shmem_startup) but before PostgreSQL boostraping code
finished, thus triggering the following assertion during a call to
LWLockAcquire():
Assert(!(proc == NULL && IsUnderPostmaster));
proc is a pointer to MyProc, a PostgreSQL's shared global variable that
was not yet initalized by PostgreSQL.
We must also check for a NULL pointer return in pg_get_backend_status()
the pgstat_fetch_stat_local_beentry() function may return a NULL pointer
during initialization, in which case we use "127.0.0.1" for the client
address, and "postmaster" for application name.
If both modules are loaded then pg_stat_monitor detects that and avoid
calling standard_ProcessUtility() in ProcessUtility_hook hook, as
calling it twice is an error and triggers an assertion on PostgreSQL.
On PostgreSQL 13, pg_stat_monitor must be loaded after
pg_stat_statements, as pg_stat_statements doesn't do such verifications,
it end calling standard_ProcessUtility() and other functions even if
another module is registered, that is an error.
They fixed this problem with pg_stat_statements in PostgreSQL 14 and onward.
The loop that resets the query buffers was incorrecly using MAX_BUCKETS
to indicate the number of buckets to clear, which defaults to 10. If a
user lowers this value the loop would access a pointer beyond the number
of query buffers allocated.
Fix the problem by using the correct PGSM_MAX_BUCKETS GUC as the limit
to the loop.
Diego Fronza
Ibrar Ahmed
Umair Shahid
EvgeniyPatlan
Oleksandr Miroshnychenko
Anastasia Alexadrova