b8bff07daa
Instead of having a separate array/hash for each resource kind, use a single array and hash to hold all kinds of resources. This makes it possible to introduce new resource "kinds" without having to modify the ResourceOwnerData struct. In particular, this makes it possible for extensions to register custom resource kinds. The old approach was to have a small array of resources of each kind, and if it fills up, switch to a hash table. The new approach also uses an array and a hash, but now the array and the hash are used at the same time. The array is used to hold the recently added resources, and when it fills up, they are moved to the hash. This keeps the access to recent entries fast, even when there are a lot of long-held resources. All the resource-specific ResourceOwnerEnlarge*(), ResourceOwnerRemember*(), and ResourceOwnerForget*() functions have been replaced with three generic functions that take resource kind as argument. For convenience, we still define resource-specific wrapper macros around the generic functions with the old names, but they are now defined in the source files that use those resource kinds. The release callback no longer needs to call ResourceOwnerForget on the resource being released. ResourceOwnerRelease unregisters the resource from the owner before calling the callback. That needed some changes in bufmgr.c and some other files, where releasing the resources previously always called ResourceOwnerForget. Each resource kind specifies a release priority, and ResourceOwnerReleaseAll releases the resources in priority order. To make that possible, we have to restrict what you can do between phases. After calling ResourceOwnerRelease(), you are no longer allowed to remember any more resources in it or to forget any previously remembered resources by calling ResourceOwnerForget. There was one case where that was done previously. At subtransaction commit, AtEOSubXact_Inval() would handle the invalidation messages and call RelationFlushRelation(), which temporarily increased the reference count on the relation being flushed. We now switch to the parent subtransaction's resource owner before calling AtEOSubXact_Inval(), so that there is a valid ResourceOwner to temporarily hold that relcache reference. Other end-of-xact routines make similar calls to AtEOXact_Inval() between release phases, but I didn't see any regression test failures from those, so I'm not sure if they could reach a codepath that needs remembering extra resources. There were two exceptions to how the resource leak WARNINGs on commit were printed previously: llvmjit silently released the context without printing the warning, and a leaked buffer io triggered a PANIC. Now everything prints a WARNING, including those cases. Add tests in src/test/modules/test_resowner. Reviewed-by: Aleksander Alekseev, Michael Paquier, Julien Rouhaud Reviewed-by: Kyotaro Horiguchi, Hayato Kuroda, Álvaro Herrera, Zhihong Yu Reviewed-by: Peter Eisentraut, Andres Freund Discussion: https://www.postgresql.org/message-id/cbfabeb0-cd3c-e951-a572-19b365ed314d%40iki.fi |
||
|---|---|---|
| .. | ||
| brin | ||
| commit_ts | ||
| delay_execution | ||
| dummy_index_am | ||
| dummy_seclabel | ||
| ldap_password_func | ||
| libpq_pipeline | ||
| plsample | ||
| spgist_name_ops | ||
| ssl_passphrase_callback | ||
| test_bloomfilter | ||
| test_copy_callbacks | ||
| test_custom_rmgrs | ||
| test_ddl_deparse | ||
| test_extensions | ||
| test_ginpostinglist | ||
| test_integerset | ||
| test_lfind | ||
| test_misc | ||
| test_oat_hooks | ||
| test_parser | ||
| test_pg_dump | ||
| test_predtest | ||
| test_rbtree | ||
| test_regex | ||
| test_resowner | ||
| test_rls_hooks | ||
| test_shm_mq | ||
| test_slru | ||
| unsafe_tests | ||
| worker_spi | ||
| Makefile | ||
| README | ||
| meson.build | ||
README
Test extensions and libraries ============================= src/test/modules contains PostgreSQL extensions that are primarily or entirely intended for testing PostgreSQL and/or to serve as example code. The extensions here aren't intended to be installed in a production server and aren't suitable for "real work". Furthermore, while you can do "make install" and "make installcheck" in this directory or its children, it is NOT ADVISABLE to do so with a server containing valuable data. Some of these tests may have undesirable side-effects on roles or other global objects within the tested server. "make installcheck-world" at the top level does not recurse into this directory. Most extensions have their own pg_regress tests or isolationtester specs. Some are also used by tests elsewhere in the tree. If you're adding new hooks or other functionality exposed as C-level API this is where to add the tests for it.