mirror of
https://git.postgresql.org/git/postgresql.git
synced 2026-02-19 12:56:59 +08:00
Previously the statistics collector received statistics updates via UDP and shared statistics data by writing them out to temporary files regularly. These files can reach tens of megabytes and are written out up to twice a second. This has repeatedly prevented us from adding additional useful statistics. Now statistics are stored in shared memory. Statistics for variable-numbered objects are stored in a dshash hashtable (backed by dynamic shared memory). Fixed-numbered stats are stored in plain shared memory. The header for pgstat.c contains an overview of the architecture. The stats collector is not needed anymore, remove it. By utilizing the transactional statistics drop infrastructure introduced in a prior commit statistics entries cannot "leak" anymore. Previously leaked statistics were dropped by pgstat_vacuum_stat(), called from [auto-]vacuum. On systems with many small relations pgstat_vacuum_stat() could be quite expensive. Now that replicas drop statistics entries for dropped objects, it is not necessary anymore to reset stats when starting from a cleanly shut down replica. Subsequent commits will perform some further code cleanup, adapt docs and add tests. Bumps PGSTAT_FILE_FORMAT_ID. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Author: Andres Freund <andres@anarazel.de> Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-By: Andres Freund <andres@anarazel.de> Reviewed-By: Thomas Munro <thomas.munro@gmail.com> Reviewed-By: Justin Pryzby <pryzby@telsasoft.com> Reviewed-By: "David G. Johnston" <david.g.johnston@gmail.com> Reviewed-By: Tomas Vondra <tomas.vondra@2ndquadrant.com> (in a much earlier version) Reviewed-By: Arthur Zakirov <a.zakirov@postgrespro.ru> (in a much earlier version) Reviewed-By: Antonin Houska <ah@cybertec.at> (in a much earlier version) Discussion: https://postgr.es/m/20220303021600.hs34ghqcw6zcokdh@alap3.anarazel.de Discussion: https://postgr.es/m/20220308205351.2xcn6k4x5yivcxyd@alap3.anarazel.de Discussion: https://postgr.es/m/20210319235115.y3wz7hpnnrshdyv6@alap3.anarazel.de
183 lines
3.2 KiB
Plaintext
183 lines
3.2 KiB
Plaintext
# This is a suppression file for use with Valgrind tools. File format
|
|
# documentation:
|
|
# http://valgrind.org/docs/manual/mc-manual.html#mc-manual.suppfiles
|
|
|
|
# The libc symbol that implements a particular standard interface is
|
|
# implementation-dependent. For example, strncpy() shows up as "__GI_strncpy"
|
|
# on some platforms. Use wildcards to avoid mentioning such specific names.
|
|
# Avoid mentioning functions that are good candidates for inlining,
|
|
# particularly single-caller static functions. Suppressions mentioning them
|
|
# would be ineffective at higher optimization levels.
|
|
|
|
|
|
# We have occasion to write raw binary structures to disk or to the network.
|
|
# These may contain uninitialized padding bytes. Since recipients also ignore
|
|
# those bytes as padding, this is harmless.
|
|
|
|
{
|
|
padding_pgstat_write
|
|
Memcheck:Param
|
|
write(buf)
|
|
|
|
...
|
|
fun:pgstat_write_statsfiles
|
|
}
|
|
|
|
{
|
|
padding_XLogRecData_CRC
|
|
Memcheck:Value8
|
|
|
|
fun:pg_comp_crc32c*
|
|
fun:XLogRecordAssemble
|
|
}
|
|
|
|
{
|
|
padding_XLogRecData_write
|
|
Memcheck:Param
|
|
pwrite64(buf)
|
|
|
|
...
|
|
fun:XLogWrite
|
|
}
|
|
|
|
{
|
|
padding_relcache
|
|
Memcheck:Param
|
|
write(buf)
|
|
|
|
...
|
|
fun:write_relcache_init_file
|
|
}
|
|
|
|
{
|
|
padding_reorderbuffer_serialize
|
|
Memcheck:Param
|
|
write(buf)
|
|
|
|
...
|
|
fun:ReorderBufferSerializeTXN
|
|
}
|
|
|
|
{
|
|
padding_twophase_prepare
|
|
Memcheck:Param
|
|
write(buf)
|
|
|
|
...
|
|
fun:EndPrepare
|
|
}
|
|
|
|
|
|
{
|
|
padding_twophase_CRC
|
|
Memcheck:Value8
|
|
fun:pg_comp_crc32c*
|
|
fun:EndPrepare
|
|
}
|
|
|
|
{
|
|
padding_bootstrap_initial_xlog_write
|
|
Memcheck:Param
|
|
write(buf)
|
|
|
|
...
|
|
fun:BootStrapXLOG
|
|
}
|
|
|
|
{
|
|
padding_bootstrap_control_file_write
|
|
Memcheck:Param
|
|
write(buf)
|
|
|
|
...
|
|
fun:WriteControlFile
|
|
fun:BootStrapXLOG
|
|
}
|
|
|
|
{
|
|
bootstrap_write_relmap_overlap
|
|
Memcheck:Overlap
|
|
fun:memcpy*
|
|
fun:write_relmap_file
|
|
fun:RelationMapFinishBootstrap
|
|
}
|
|
|
|
|
|
# gcc on ppc64 can generate a four-byte read to fetch the final "char" fields
|
|
# of a FormData_pg_cast. This is valid compiler behavior, because a proper
|
|
# FormData_pg_cast has trailing padding. Tuples we treat as structures omit
|
|
# that padding, so Valgrind reports an invalid read. Practical trouble would
|
|
# entail the missing pad bytes falling in a different memory page. So long as
|
|
# the structure is aligned, that will not happen.
|
|
{
|
|
overread_tuplestruct_pg_cast
|
|
Memcheck:Addr4
|
|
|
|
fun:IsBinaryCoercible
|
|
}
|
|
|
|
# Python's allocator does some low-level tricks for efficiency. Those
|
|
# can be disabled for better instrumentation; but few people testing
|
|
# postgres will have such a build of python. So add broad
|
|
# suppressions of the resulting errors.
|
|
# See also https://svn.python.org/projects/python/trunk/Misc/README.valgrind
|
|
{
|
|
python_clever_allocator
|
|
Memcheck:Addr4
|
|
fun:PyObject_Free
|
|
}
|
|
|
|
{
|
|
python_clever_allocator
|
|
Memcheck:Addr8
|
|
fun:PyObject_Free
|
|
}
|
|
|
|
{
|
|
python_clever_allocator
|
|
Memcheck:Value4
|
|
fun:PyObject_Free
|
|
}
|
|
|
|
{
|
|
python_clever_allocator
|
|
Memcheck:Value8
|
|
fun:PyObject_Free
|
|
}
|
|
|
|
{
|
|
python_clever_allocator
|
|
Memcheck:Cond
|
|
fun:PyObject_Free
|
|
}
|
|
|
|
{
|
|
python_clever_allocator
|
|
Memcheck:Addr4
|
|
fun:PyObject_Realloc
|
|
}
|
|
|
|
{
|
|
python_clever_allocator
|
|
Memcheck:Addr8
|
|
fun:PyObject_Realloc
|
|
}
|
|
|
|
{
|
|
python_clever_allocator
|
|
Memcheck:Value4
|
|
fun:PyObject_Realloc
|
|
}
|
|
|
|
{
|
|
python_clever_allocator
|
|
Memcheck:Value8
|
|
fun:PyObject_Realloc
|
|
}
|
|
|
|
{
|
|
python_clever_allocator
|
|
Memcheck:Cond
|
|
fun:PyObject_Realloc
|
|
}
|