spock.supp

# We don't care about leaks in work done only once
# during startup, so suppress them. We could possibly free
# these cleanly, but ... meh.

{
   spk_apply_start_sync_sub
   Memcheck:Leak
   match-leak-kinds: possible,definite,reachable
   fun:*lloc*
   ...
   fun:spock_sync_subscription
   fun:spock_apply_main
}

{
   spk_apply_start_getsub
   Memcheck:Leak
   match-leak-kinds: possible,definite,reachable
   fun:*lloc*
   ...
   fun:get_subscription
   fun:spock_apply_main
}

{
   spk_apply_start_queuetable
   Memcheck:Leak
   match-leak-kinds: possible,definite,reachable
   fun:*lloc*
   ...
   fun:get_queue_table_oid
   fun:spock_apply_main
}

{
   spk_apply_start_bgw
   Memcheck:Leak
   match-leak-kinds: possible,definite,reachable
   fun:*lloc*
   ...
   fun:BackgroundWorkerInitializeConnectionByOid
   fun:spock_apply_main
}

{
   spk_apply_start_replorigin
   Memcheck:Leak
   match-leak-kinds: possible,definite,reachable
   fun:*lloc*
   ...
   fun:replorigin_by_name
   fun:spock_apply_main
}

{
   spk_apply_start_resowner
   Memcheck:Leak
   match-leak-kinds: definite,definite,reachable
   fun:*lloc*
   ...
   fun:ResourceOwnerCreate
   fun:spock_apply_main
}

{
   spk_bgw_init
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:RegisterBackgroundWorker
   fun:_PG_init
}

#
# spock's relcache persists across txns.
#
# These allocations are in CacheMemoryContext.
#

{
   spk_relcache_update
   Memcheck:Leak
   match-leak-kinds: possible
   fun:*lloc*
   ...
   fun:spock_relation_cache_update
   ...
   fun:apply_work
}

{
   spk_relcache_open
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:*lloc*
   ...
   fun:spock_relation_open
}


#
#
# These produce a lot of noise. They may be real leaks and need looking into,
# but are suppressed for now while I look for other issues. Pg should complain
# if we fail to close an opened relation.
#

{
   spk_relation
   Memcheck:Leak
   match-leak-kinds: possible
   fun:*lloc*
   ...
   fun:relation_open
}

{
   spk_relation
   Memcheck:Leak
   match-leak-kinds: possible
   fun:*lloc*
   ...
   fun:relation_open
}
#
# XXX
#
# Valgrind keeps claiming that bms_copy escapes heap_update. I cannot find how
# that could be happening. We'll suppress the report for now on the assumption
# that anything happening this deep in Pg should be causing much greater upset
# than in spk, but it merits further digging.
#

{
   spk_pg_bms_copy
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:palloc
   fun:bms_copy
   fun:RelationGetIndexAttrBitmap
   fun:heap_update
   ...
   fun:standard_ProcessUtility
   fun:spock_ProcessUtility
   ...
   fun:handle_sql
   ...
   fun:apply_work
}

# Anything else in standard_ProcessUtility called via spock_ProcessUtility
# during spk SQL execution.
#
# This MUST not be invoked in TopMemoryContext, and so long as txn state is sane
# cannot then allocate into TopMemoryContext. (Shame Valgrind doesn't let us name
# mempools for allocations).
{
   spk_sql_processutility
   Memcheck:Leak
   match-leak-kinds: reachable,possible
   fun:*lloc*
   ...
   fun:standard_ProcessUtility
   fun:spock_ProcessUtility
   ...
   fun:handle_sql
   ...
   fun:apply_work
   fun:spock_apply_main
}


#
# XXX uncertain
#
# We're a bit suss about this one
#
{
   <insert_a_suppression_name_here>
   Memcheck:Leak
   match-leak-kinds: possible
   fun:MemoryContextAlloc
   fun:MemoryContextStrdup
   fun:spock_relation_cache_update
   fun:spock_read_rel
   fun:handle_relation
   fun:replication_handler
   fun:apply_work
}


#
# Core postgres noise. It doesn't try to be memcheck friendly.
#

{
   pg_conffile
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   ...
   fun:guc_strdup
   ...
   fun:ProcessConfigFile
}

{
   pg_start
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:BackendStartup
   fun:ServerLoop
   fun:PostmasterMain
   fun:main
}

{
   pg_bgw
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   ...
   fun:do_start_bgworker
   fun:maybe_start_bgworkers
}

{
   pg_bgw_register
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:RegisterBackgroundWorker
   fun:ApplyLauncherRegister
   fun:PostmasterMain
   fun:main
}

{
   pg_init_locks
   Memcheck:Leak
   match-leak-kinds: possible
   fun:MemoryContextAlloc*
   ...
   fun:InitLocks
   fun:CreateSharedMemoryAndSemaphores
   fun:reset_shared
   fun:PostmasterMain
   fun:main
}

{
   pg_bgw_state
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:BackgroundWorkerStateChange
}

{
   pg_ps_display
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   fun:save_ps_display_args
   fun:main
}

#
# Pg's hash impl looks like it confuses valgrind
# (but verify TODO)
#
{
   pg_hash
   Memcheck:Leak
   match-leak-kinds: possible
   ...
   fun:element_alloc
   fun:get_hash_entry
   fun:hash_search_with_hash_value
}

{
   pg_pmmain_blah
   Memcheck:Leak
   match-leak-kinds: definite
   fun:malloc
   fun:strdup
   fun:PostmasterMain
   fun:main
}

{
   pg_tz
   Memcheck:Leak
   match-leak-kinds: possible
   fun:MemoryContextAlloc
   fun:element_alloc
   fun:hash_create
   fun:init_timezone_hashtable
   fun:pg_tzset
   fun:pg_timezone_initialize
   fun:InitializeGUCOptions
   fun:PostmasterMain
   fun:main
}

{
   pg_vac
   Memcheck:Leak
   match-leak-kinds: possible
   fun:malloc
   fun:StartAutovacuumWorker
}

{
   pg_InitPostgres
   Memcheck:Leak
   match-leak-kinds: possible
   fun:*lloc*
   ...
   fun:InitPostgres
   fun:PostgresMain
}


# "reachable"-only suppressions. These are used when we're looking for memory
# we can still access but are progressively allocating more of during long
# running processes like the apply worker our output plugin. To find them
# we must exclude things we're keeping around on purpose.
#

# This is allocated once on entry to apply_work
{
   spk_reachable_msgcontext
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:MemoryContextAlloc
   fun:MemoryContextCreate
   fun:AllocSetContextCreate
   fun:apply_work
   fun:spock_apply_main
}

# This is stashed in a static var on first allocation and reused. It
# shouldn't grow.
{
   spk_reachable_feedback
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:palloc
   ...
   fun:makeStringInfo
   fun:send_feedback
   fun:apply_work
   fun:spock_apply_main
}

# It's typical for syscache and catcache entries to live beyond a single txn.
# That's kind of the point. If spk fails to release cache entries that's not
# something we can detect easily, except maybe with CLOBBER_CACHE_ALWAYS,
# which runs like treacle under valgrind.
{
   pg_reachable_catcache
   Memcheck:Leak
   match-leak-kinds: reachable,possible
   fun:*lloc*
   ...
   fun:SearchCatCache
}

# RelationGetIndexList adds indexes to the relcache. But importantly
# it returns a list_copy of the result, so we must not filter out the
# allocation there, only the cached stuff.
{
   pg_reachable_indexlist
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:MemoryContextAlloc*
   ...
   fun:index_open
   ...
   fun:RelationGetIndexList
}

# GUCs normally have extended lifetimes
{
   pg_reachable_guc
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:strdup
   fun:guc_strdup
}

{
   pg_reachable_guc_check
   Memcheck:Leak
   match-leak-kinds: reachable,possible
   fun:*lloc*
   fun:check_role
   ...
   fun:parse_and_validate_value
   fun:set_config_option
}

# Lots of things in standard_ProcessUtility mess with the syscache
# and they're not going to leak.
{
   pg_reachable_processutility
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:*lloc*
   ...
   fun:relation_open
   ...
   fun:standard_ProcessUtility
}

# The smgr and md layer keep track of their own resources. If we fail to close
# relations we should see it at a higher level. We can see these allocations
# from random heap operations because smgr relation opening happens lazily, not
# at heap_open time.
{
   pg_mdopen
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:*lloc*
   ...
   fun:mdopen
}

#
# This report looks bogus. There should be no way for the allocated wait-event
# set to escape WaitLatchOrSocket. In spk it only arises once anyway.
#
{
   pg_waitlatchorsocket
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:malloc
   fun:AllocSetAlloc
   fun:MemoryContextAllocZero
   fun:CreateWaitEventSet
   fun:WaitLatchOrSocket
}

#
# If we test across a txn boundary we may see pgstat allocations, and
# that's OK, we clean them later.
#
{
   pg_pgstat
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:MemoryContextAlloc
   fun:get_tabstat_stack_level
}

#
# Again, lock acquisition during heap_openrv can seem to leak if
# we do a leakcheck during a txn. It's fine, pg will complain
# if we fail to close relations.
#
{
   pg_heap_openrv
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:*lloc*
   ...
   fun:heap_openrv
}

{
   pg_table_openrv
   Memcheck:Leak
   match-leak-kinds: reachable
   fun:*lloc*
   ...
   fun:table_openrv
}

#
# Tupledescs are refcounted. Any check we do during a txn
# will show such output.
#
#{
#   pg_tupledesc_count
#   Memcheck:Leak
#   match-leak-kinds: reachable
#   fun:MemoryContextAlloc
#   fun:ResourceArrayEnlarge.part.4
#   fun:IncrTupleDescRefCount
#   fun:ExecSetSlotDescriptor
#}