2004-07-17 05:32:14 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* resowner.h
|
|
|
|
* POSTGRES resource owner definitions.
|
|
|
|
*
|
|
|
|
* Query-lifespan resources are tracked by associating them with
|
|
|
|
* ResourceOwner objects. This provides a simple mechanism for ensuring
|
|
|
|
* that such resources are freed at the right time.
|
|
|
|
* See utils/resowner/README for more info.
|
|
|
|
*
|
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
2004-07-17 05:32:14 +02:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/utils/resowner.h
|
2004-07-17 05:32:14 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef RESOWNER_H
|
|
|
|
#define RESOWNER_H
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* ResourceOwner objects are an opaque data structure known only within
|
|
|
|
* resowner.c.
|
|
|
|
*/
|
|
|
|
typedef struct ResourceOwnerData *ResourceOwner;
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Globally known ResourceOwners
|
|
|
|
*/
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT ResourceOwner CurrentResourceOwner;
|
|
|
|
extern PGDLLIMPORT ResourceOwner CurTransactionResourceOwner;
|
|
|
|
extern PGDLLIMPORT ResourceOwner TopTransactionResourceOwner;
|
Use a ResourceOwner to track buffer pins in all cases.
Historically, we've allowed auxiliary processes to take buffer pins without
tracking them in a ResourceOwner. However, that creates problems for error
recovery. In particular, we've seen multiple reports of assertion crashes
in the startup process when it gets an error while holding a buffer pin,
as for example if it gets ENOSPC during a write. In a non-assert build,
the process would simply exit without releasing the pin at all. We've
gotten away with that so far just because a failure exit of the startup
process translates to a database crash anyhow; but any similar behavior
in other aux processes could result in stuck pins and subsequent problems
in vacuum.
To improve this, institute a policy that we must *always* have a resowner
backing any attempt to pin a buffer, which we can enforce just by removing
the previous special-case code in resowner.c. Add infrastructure to make
it easy to create a process-lifespan AuxProcessResourceOwner and clear
out its contents at appropriate times. Replace existing ad-hoc resowner
management in bgwriter.c and other aux processes with that. (Thus, while
the startup process gains a resowner where it had none at all before, some
other aux process types are replacing an ad-hoc resowner with this code.)
Also use the AuxProcessResourceOwner to manage buffer pins taken during
StartupXLOG and ShutdownXLOG, even when those are being run in a bootstrap
process or a standalone backend rather than a true auxiliary process.
In passing, remove some other ad-hoc resource owner creations that had
gotten cargo-culted into various other places. As far as I can tell
that was all unnecessary, and if it had been necessary it was incomplete,
due to lacking any provision for clearing those resowners later.
(Also worth noting in this connection is that a process that hasn't called
InitBufferPoolBackend has no business accessing buffers; so there's more
to do than just add the resowner if we want to touch buffers in processes
not covered by this patch.)
Although this fixes a very old bug, no back-patch, because there's no
evidence of any significant problem in non-assert builds.
Patch by me, pursuant to a report from Justin Pryzby. Thanks to
Robert Haas and Kyotaro Horiguchi for reviews.
Discussion: https://postgr.es/m/20180627233939.GA10276@telsasoft.com
2018-07-18 18:15:16 +02:00
|
|
|
extern PGDLLIMPORT ResourceOwner AuxProcessResourceOwner;
|
2004-07-17 05:32:14 +02:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Resource releasing is done in three phases: pre-locks, locks, and
|
2014-05-06 18:12:18 +02:00
|
|
|
* post-locks. The pre-lock phase must release any resources that are
|
2004-07-17 05:32:14 +02:00
|
|
|
* visible to other backends (such as pinned buffers); this ensures that
|
|
|
|
* when we release a lock that another backend may be waiting on, it will
|
|
|
|
* see us as being fully out of our transaction. The post-lock phase
|
|
|
|
* should be used for backend-internal cleanup.
|
|
|
|
*/
|
|
|
|
typedef enum
|
|
|
|
{
|
|
|
|
RESOURCE_RELEASE_BEFORE_LOCKS,
|
|
|
|
RESOURCE_RELEASE_LOCKS,
|
|
|
|
RESOURCE_RELEASE_AFTER_LOCKS
|
|
|
|
} ResourceReleasePhase;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Dynamically loaded modules can get control during ResourceOwnerRelease
|
|
|
|
* by providing a callback of this form.
|
|
|
|
*/
|
|
|
|
typedef void (*ResourceReleaseCallback) (ResourceReleasePhase phase,
|
2017-06-21 20:39:04 +02:00
|
|
|
bool isCommit,
|
|
|
|
bool isTopLevel,
|
|
|
|
void *arg);
|
2004-07-17 05:32:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Functions in resowner.c
|
|
|
|
*/
|
|
|
|
|
|
|
|
/* generic routines */
|
|
|
|
extern ResourceOwner ResourceOwnerCreate(ResourceOwner parent,
|
2019-05-22 19:04:48 +02:00
|
|
|
const char *name);
|
2004-07-17 05:32:14 +02:00
|
|
|
extern void ResourceOwnerRelease(ResourceOwner owner,
|
2019-05-22 19:04:48 +02:00
|
|
|
ResourceReleasePhase phase,
|
|
|
|
bool isCommit,
|
|
|
|
bool isTopLevel);
|
2004-07-17 05:32:14 +02:00
|
|
|
extern void ResourceOwnerDelete(ResourceOwner owner);
|
2004-08-27 19:07:42 +02:00
|
|
|
extern ResourceOwner ResourceOwnerGetParent(ResourceOwner owner);
|
2004-07-17 05:32:14 +02:00
|
|
|
extern void ResourceOwnerNewParent(ResourceOwner owner,
|
2019-05-22 19:04:48 +02:00
|
|
|
ResourceOwner newparent);
|
2004-07-17 05:32:14 +02:00
|
|
|
extern void RegisterResourceReleaseCallback(ResourceReleaseCallback callback,
|
2019-05-22 19:04:48 +02:00
|
|
|
void *arg);
|
2004-07-17 05:32:14 +02:00
|
|
|
extern void UnregisterResourceReleaseCallback(ResourceReleaseCallback callback,
|
2019-05-22 19:04:48 +02:00
|
|
|
void *arg);
|
Use a ResourceOwner to track buffer pins in all cases.
Historically, we've allowed auxiliary processes to take buffer pins without
tracking them in a ResourceOwner. However, that creates problems for error
recovery. In particular, we've seen multiple reports of assertion crashes
in the startup process when it gets an error while holding a buffer pin,
as for example if it gets ENOSPC during a write. In a non-assert build,
the process would simply exit without releasing the pin at all. We've
gotten away with that so far just because a failure exit of the startup
process translates to a database crash anyhow; but any similar behavior
in other aux processes could result in stuck pins and subsequent problems
in vacuum.
To improve this, institute a policy that we must *always* have a resowner
backing any attempt to pin a buffer, which we can enforce just by removing
the previous special-case code in resowner.c. Add infrastructure to make
it easy to create a process-lifespan AuxProcessResourceOwner and clear
out its contents at appropriate times. Replace existing ad-hoc resowner
management in bgwriter.c and other aux processes with that. (Thus, while
the startup process gains a resowner where it had none at all before, some
other aux process types are replacing an ad-hoc resowner with this code.)
Also use the AuxProcessResourceOwner to manage buffer pins taken during
StartupXLOG and ShutdownXLOG, even when those are being run in a bootstrap
process or a standalone backend rather than a true auxiliary process.
In passing, remove some other ad-hoc resource owner creations that had
gotten cargo-culted into various other places. As far as I can tell
that was all unnecessary, and if it had been necessary it was incomplete,
due to lacking any provision for clearing those resowners later.
(Also worth noting in this connection is that a process that hasn't called
InitBufferPoolBackend has no business accessing buffers; so there's more
to do than just add the resowner if we want to touch buffers in processes
not covered by this patch.)
Although this fixes a very old bug, no back-patch, because there's no
evidence of any significant problem in non-assert builds.
Patch by me, pursuant to a report from Justin Pryzby. Thanks to
Robert Haas and Kyotaro Horiguchi for reviews.
Discussion: https://postgr.es/m/20180627233939.GA10276@telsasoft.com
2018-07-18 18:15:16 +02:00
|
|
|
extern void CreateAuxProcessResourceOwner(void);
|
|
|
|
extern void ReleaseAuxProcessResources(bool isCommit);
|
2004-07-17 05:32:14 +02:00
|
|
|
|
Phase 2 of pgindent updates.
Change pg_bsd_indent to follow upstream rules for placement of comments
to the right of code, and remove pgindent hack that caused comments
following #endif to not obey the general rule.
Commit e3860ffa4dd0dad0dd9eea4be9cc1412373a8c89 wasn't actually using
the published version of pg_bsd_indent, but a hacked-up version that
tried to minimize the amount of movement of comments to the right of
code. The situation of interest is where such a comment has to be
moved to the right of its default placement at column 33 because there's
code there. BSD indent has always moved right in units of tab stops
in such cases --- but in the previous incarnation, indent was working
in 8-space tab stops, while now it knows we use 4-space tabs. So the
net result is that in about half the cases, such comments are placed
one tab stop left of before. This is better all around: it leaves
more room on the line for comment text, and it means that in such
cases the comment uniformly starts at the next 4-space tab stop after
the code, rather than sometimes one and sometimes two tabs after.
Also, ensure that comments following #endif are indented the same
as comments following other preprocessor commands such as #else.
That inconsistency turns out to have been self-inflicted damage
from a poorly-thought-through post-indent "fixup" in pgindent.
This patch is much less interesting than the first round of indent
changes, but also bulkier, so I thought it best to separate the effects.
Discussion: https://postgr.es/m/E1dAmxK-0006EE-1r@gemulon.postgresql.org
Discussion: https://postgr.es/m/30527.1495162840@sss.pgh.pa.us
2017-06-21 21:18:54 +02:00
|
|
|
#endif /* RESOWNER_H */
|