2004-05-30 00:48:23 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* bgwriter.h
|
Improve control logic for bgwriter hibernation mode.
Commit 6d90eaaa89a007e0d365f49d6436f35d2392cfeb added a hibernation mode
to the bgwriter to reduce the server's idle-power consumption. However,
its interaction with the detailed behavior of BgBufferSync's feedback
control loop wasn't very well thought out. That control loop depends
primarily on the rate of buffer allocation, not the rate of buffer
dirtying, so the hibernation mode has to be designed to operate only when
no new buffer allocations are happening. Also, the check for whether the
system is effectively idle was not quite right and would fail to detect
a constant low level of activity, thus allowing the bgwriter to go into
hibernation mode in a way that would let the cycle time vary quite a bit,
possibly further confusing the feedback loop. To fix, move the wakeup
support from MarkBufferDirty and SetBufferCommitInfoNeedsSave into
StrategyGetBuffer, and prevent the bgwriter from entering hibernation mode
unless no buffer allocations have happened recently.
In addition, fix the delaying logic to remove the problem of possibly not
responding to signals promptly, which was basically caused by trying to use
the process latch's is_set flag for multiple purposes. I can't prove it
but I'm suspicious that that hack was responsible for the intermittent
"postmaster does not shut down" failures we've been seeing in the buildfarm
lately. In any case it did nothing to improve the readability or
robustness of the code.
In passing, express the hibernation sleep time as a multiplier on
BgWriterDelay, not a constant. I'm not sure whether there's any value in
exposing the longer sleep time as an independently configurable setting,
but we can at least make it act like this for little extra code.
2012-05-10 05:36:01 +02:00
|
|
|
* Exports from postmaster/bgwriter.c and postmaster/checkpointer.c.
|
|
|
|
*
|
|
|
|
* The bgwriter process used to handle checkpointing duties too. Now
|
|
|
|
* there is a separate process, but we did not bother to split this header.
|
2004-05-30 00:48:23 +02:00
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
2004-05-30 00:48:23 +02:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/postmaster/bgwriter.h
|
2004-05-30 00:48:23 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef _BGWRITER_H
|
|
|
|
#define _BGWRITER_H
|
|
|
|
|
2004-05-31 05:48:10 +02:00
|
|
|
#include "storage/block.h"
|
|
|
|
#include "storage/relfilenode.h"
|
|
|
|
|
|
|
|
|
2004-05-30 00:48:23 +02:00
|
|
|
/* GUC options */
|
|
|
|
extern int BgWriterDelay;
|
|
|
|
extern int CheckPointTimeout;
|
|
|
|
extern int CheckPointWarning;
|
2007-06-28 02:02:40 +02:00
|
|
|
extern double CheckPointCompletionTarget;
|
2004-05-30 00:48:23 +02:00
|
|
|
|
2015-03-26 19:03:19 +01:00
|
|
|
extern void BackgroundWriterMain(void) pg_attribute_noreturn();
|
|
|
|
extern void CheckpointerMain(void) pg_attribute_noreturn();
|
2004-05-30 00:48:23 +02:00
|
|
|
|
2007-06-28 02:02:40 +02:00
|
|
|
extern void RequestCheckpoint(int flags);
|
|
|
|
extern void CheckpointWriteDelay(int flags, double progress);
|
2004-05-30 00:48:23 +02:00
|
|
|
|
Improve coding around the fsync request queue.
In all branches back to 8.3, this patch fixes a questionable assumption in
CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue that there are
no uninitialized pad bytes in the request queue structs. This would only
cause trouble if (a) there were such pad bytes, which could happen in 8.4
and up if the compiler makes enum ForkNumber narrower than 32 bits, but
otherwise would require not-currently-planned changes in the widths of
other typedefs; and (b) the kernel has not uniformly initialized the
contents of shared memory to zeroes. Still, it seems a tad risky, and we
can easily remove any risk by pre-zeroing the request array for ourselves.
In addition to that, we need to establish a coding rule that struct
RelFileNode can't contain any padding bytes, since such structs are copied
into the request array verbatim. (There are other places that are assuming
this anyway, it turns out.)
In 9.1 and up, the risk was a bit larger because we were also effectively
assuming that struct RelFileNodeBackend contained no pad bytes, and with
fields of different types in there, that would be much easier to break.
However, there is no good reason to ever transmit fsync or delete requests
for temp files to the bgwriter/checkpointer, so we can revert the request
structs to plain RelFileNode, getting rid of the padding risk and saving
some marginal number of bytes and cycles in fsync queue manipulation while
we are at it. The savings might be more than marginal during deletion of
a temp relation, because the old code transmitted an entirely useless but
nonetheless expensive-to-process ForgetRelationFsync request to the
background process, and also had the background process perform the file
deletion even though that can safely be done immediately.
In addition, make some cleanup of nearby comments and small improvements to
the code in CompactCheckpointerRequestQueue/CompactBgwriterRequestQueue.
2012-07-17 22:55:39 +02:00
|
|
|
extern bool ForwardFsyncRequest(RelFileNode rnode, ForkNumber forknum,
|
2009-06-11 16:49:15 +02:00
|
|
|
BlockNumber segno);
|
2004-05-31 05:48:10 +02:00
|
|
|
extern void AbsorbFsyncRequests(void);
|
|
|
|
|
2012-05-09 15:23:45 +02:00
|
|
|
extern Size CheckpointerShmemSize(void);
|
|
|
|
extern void CheckpointerShmemInit(void);
|
2004-05-30 00:48:23 +02:00
|
|
|
|
2012-06-01 10:24:53 +02:00
|
|
|
extern bool FirstCallSinceLastCheckpoint(void);
|
|
|
|
|
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 /* _BGWRITER_H */
|