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 |
||
|---|---|---|
| .. | ||
| activity | ||
| adt | ||
| cache | ||
| error | ||
| fmgr | ||
| hash | ||
| init | ||
| mb | ||
| misc | ||
| mmgr | ||
| resowner | ||
| sort | ||
| time | ||
| .gitignore | ||
| Gen_dummy_probes.pl | ||
| Gen_dummy_probes.pl.prolog | ||
| Gen_dummy_probes.sed | ||
| Gen_fmgrtab.pl | ||
| Makefile | ||
| README.Gen_dummy_probes | ||
| errcodes.txt | ||
| generate-errcodes.pl | ||
| meson.build | ||
| postprocess_dtrace.sed | ||
| probes.d | ||
README.Gen_dummy_probes
# Generating dummy probes If Postgres isn't configured with dtrace enabled, we need to generate dummy probes for the entries in probes.d, that do nothing. This is accomplished in Unix via the sed script `Gen_dummy_probes.sed`. We used to use this in MSVC builds using the perl utility `psed`, which mimicked sed. However, that utility disappeared from Windows perl distributions and so we converted the sed script to a perl script to be used in MSVC builds. We still keep the sed script as the authoritative source for generating these dummy probes because except on Windows perl is not a hard requirement when building from a tarball. So, if you need to change the way dummy probes are generated, first change the sed script, and when it's working generate the perl script. This can be accomplished by using the perl utility s2p. s2p is no longer part of the perl core, so it might not be on your system, but it is available on CPAN and also in many package systems. e.g. on Fedora it can be installed using `cpan App::s2p` or `dnf install perl-App-s2p`. The Makefile contains a recipe for regenerating Gen_dummy_probes.pl, so all you need to do is once you have s2p installed is `make Gen_dummy_probes.pl` Note that in a VPATH build this will generate the file in the vpath tree, not the source tree.