1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* globals.c
|
1996-07-09 08:22:35 +02:00
|
|
|
* global variable declarations
|
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/utils/init/globals.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* NOTES
|
|
|
|
* Globals used all over the place should be declared here and not
|
|
|
|
* in other modules.
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
XLOG (and related) changes:
* Store two past checkpoint locations, not just one, in pg_control.
On startup, we fall back to the older checkpoint if the newer one
is unreadable. Also, a physical copy of the newest checkpoint record
is kept in pg_control for possible use in disaster recovery (ie,
complete loss of pg_xlog). Also add a version number for pg_control
itself. Remove archdir from pg_control; it ought to be a GUC
parameter, not a special case (not that it's implemented yet anyway).
* Suppress successive checkpoint records when nothing has been entered
in the WAL log since the last one. This is not so much to avoid I/O
as to make it actually useful to keep track of the last two
checkpoints. If the things are right next to each other then there's
not a lot of redundancy gained...
* Change CRC scheme to a true 64-bit CRC, not a pair of 32-bit CRCs
on alternate bytes. Polynomial borrowed from ECMA DLT1 standard.
* Fix XLOG record length handling so that it will work at BLCKSZ = 32k.
* Change XID allocation to work more like OID allocation. (This is of
dubious necessity, but I think it's a good idea anyway.)
* Fix a number of minor bugs, such as off-by-one logic for XLOG file
wraparound at the 4 gig mark.
* Add documentation and clean up some coding infelicities; move file
format declarations out to include files where planned contrib
utilities can get at them.
* Checkpoint will now occur every CHECKPOINT_SEGMENTS log segments or
every CHECKPOINT_TIMEOUT seconds, whichever comes first. It is also
possible to force a checkpoint by sending SIGUSR1 to the postmaster
(undocumented feature...)
* Defend against kill -9 postmaster by storing shmem block's key and ID
in postmaster.pid lockfile, and checking at startup to ensure that no
processes are still connected to old shmem block (if it still exists).
* Switch backends to accept SIGQUIT rather than SIGUSR1 for emergency
stop, for symmetry with postmaster and xlog utilities. Clean up signal
handling in bootstrap.c so that xlog utilities launched by postmaster
will react to signals better.
* Standalone bootstrap now grabs lockfile in target directory, as added
insurance against running it in parallel with live postmaster.
2001-03-13 02:17:06 +01:00
|
|
|
#include "postgres.h"
|
|
|
|
|
2018-04-07 23:45:39 +02:00
|
|
|
#include "common/file_perm.h"
|
2014-02-09 03:21:46 +01:00
|
|
|
#include "libpq/libpq-be.h"
|
1999-07-16 07:23:30 +02:00
|
|
|
#include "libpq/pqcomm.h"
|
|
|
|
#include "miscadmin.h"
|
2024-03-03 18:38:22 +01:00
|
|
|
#include "storage/procnumber.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2001-06-12 07:55:50 +02:00
|
|
|
|
2009-08-28 20:23:53 +02:00
|
|
|
ProtocolVersion FrontendProtocol;
|
1998-05-19 20:05:58 +02:00
|
|
|
|
2018-09-27 00:47:20 +02:00
|
|
|
volatile sig_atomic_t InterruptPending = false;
|
|
|
|
volatile sig_atomic_t QueryCancelPending = false;
|
|
|
|
volatile sig_atomic_t ProcDiePending = false;
|
2021-04-02 21:52:30 +02:00
|
|
|
volatile sig_atomic_t CheckClientConnectionPending = false;
|
2018-09-27 00:47:20 +02:00
|
|
|
volatile sig_atomic_t ClientConnectionLost = false;
|
|
|
|
volatile sig_atomic_t IdleInTransactionSessionTimeoutPending = false;
|
2024-02-15 22:34:11 +01:00
|
|
|
volatile sig_atomic_t TransactionTimeoutPending = false;
|
2021-01-07 00:28:42 +01:00
|
|
|
volatile sig_atomic_t IdleSessionTimeoutPending = false;
|
2019-12-19 20:56:20 +01:00
|
|
|
volatile sig_atomic_t ProcSignalBarrierPending = false;
|
Add function to log the memory contexts of specified backend process.
Commit 3e98c0bafb added pg_backend_memory_contexts view to display
the memory contexts of the backend process. However its target process
is limited to the backend that is accessing to the view. So this is
not so convenient when investigating the local memory bloat of other
backend process. To improve this situation, this commit adds
pg_log_backend_memory_contexts() function that requests to log
the memory contexts of the specified backend process.
This information can be also collected by calling
MemoryContextStats(TopMemoryContext) via a debugger. But
this technique cannot be used in some environments because no debugger
is available there. So, pg_log_backend_memory_contexts() allows us to
see the memory contexts of specified backend more easily.
Only superusers are allowed to request to log the memory contexts
because allowing any users to issue this request at an unbounded rate
would cause lots of log messages and which can lead to denial of service.
On receipt of the request, at the next CHECK_FOR_INTERRUPTS(),
the target backend logs its memory contexts at LOG_SERVER_ONLY level,
so that these memory contexts will appear in the server log but not
be sent to the client. It logs one message per memory context.
Because if it buffers all memory contexts into StringInfo to log them
as one message, which may require the buffer to be enlarged very much
and lead to OOM error since there can be a large number of memory
contexts in a backend.
When a backend process is consuming huge memory, logging all its
memory contexts might overrun available disk space. To prevent this,
now this patch limits the number of child contexts to log per parent
to 100. As with MemoryContextStats(), it supposes that practical cases
where the log gets long will typically be huge numbers of siblings
under the same parent context; while the additional debugging value
from seeing details about individual siblings beyond 100 will not be large.
There was another proposed patch to add the function to return
the memory contexts of specified backend as the result sets,
instead of logging them, in the discussion. However that patch is
not included in this commit because it had several issues to address.
Thanks to Tatsuhito Kasahara, Andres Freund, Tom Lane, Tomas Vondra,
Michael Paquier, Kyotaro Horiguchi and Zhihong Yu for the discussion.
Bump catalog version.
Author: Atsushi Torikoshi
Reviewed-by: Kyotaro Horiguchi, Zhihong Yu, Fujii Masao
Discussion: https://postgr.es/m/0271f440ac77f2a4180e0e56ebd944d1@oss.nttdata.com
2021-04-06 06:44:15 +02:00
|
|
|
volatile sig_atomic_t LogMemoryContextPending = false;
|
2022-04-07 06:29:46 +02:00
|
|
|
volatile sig_atomic_t IdleStatsUpdateTimeoutPending = false;
|
2001-01-19 23:08:47 +01:00
|
|
|
volatile uint32 InterruptHoldoffCount = 0;
|
Be more careful to not lose sync in the FE/BE protocol.
If any error occurred while we were in the middle of reading a protocol
message from the client, we could lose sync, and incorrectly try to
interpret a part of another message as a new protocol message. That will
usually lead to an "invalid frontend message" error that terminates the
connection. However, this is a security issue because an attacker might
be able to deliberately cause an error, inject a Query message in what's
supposed to be just user data, and have the server execute it.
We were quite careful to not have CHECK_FOR_INTERRUPTS() calls or other
operations that could ereport(ERROR) in the middle of processing a message,
but a query cancel interrupt or statement timeout could nevertheless cause
it to happen. Also, the V2 fastpath and COPY handling were not so careful.
It's very difficult to recover in the V2 COPY protocol, so we will just
terminate the connection on error. In practice, that's what happened
previously anyway, as we lost protocol sync.
To fix, add a new variable in pqcomm.c, PqCommReadingMsg, that is set
whenever we're in the middle of reading a message. When it's set, we cannot
safely ERROR out and continue running, because we might've read only part
of a message. PqCommReadingMsg acts somewhat similarly to critical sections
in that if an error occurs while it's set, the error handler will force the
connection to be terminated, as if the error was FATAL. It's not
implemented by promoting ERROR to FATAL in elog.c, like ERROR is promoted
to PANIC in critical sections, because we want to be able to use
PG_TRY/CATCH to recover and regain protocol sync. pq_getmessage() takes
advantage of that to prevent an OOM error from terminating the connection.
To prevent unnecessary connection terminations, add a holdoff mechanism
similar to HOLD/RESUME_INTERRUPTS() that can be used hold off query cancel
interrupts, but still allow die interrupts. The rules on which interrupts
are processed when are now a bit more complicated, so refactor
ProcessInterrupts() and the calls to it in signal handlers so that the
signal handlers always call it if ImmediateInterruptOK is set, and
ProcessInterrupts() can decide to not do anything if the other conditions
are not met.
Reported by Emil Lenngren. Patch reviewed by Noah Misch and Andres Freund.
Backpatch to all supported versions.
Security: CVE-2015-0244
2015-02-02 16:08:45 +01:00
|
|
|
volatile uint32 QueryCancelHoldoffCount = 0;
|
2001-01-14 06:08:17 +01:00
|
|
|
volatile uint32 CritSectionCount = 0;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
1998-01-25 06:15:15 +01:00
|
|
|
int MyProcPid;
|
2008-02-17 03:09:32 +01:00
|
|
|
pg_time_t MyStartTime;
|
2018-10-19 02:59:14 +02:00
|
|
|
TimestampTz MyStartTimestamp;
|
2024-03-18 10:35:08 +01:00
|
|
|
struct ClientSocket *MyClientSocket;
|
1998-08-25 23:24:12 +02:00
|
|
|
struct Port *MyProcPort;
|
Replace PostmasterRandom() with a stronger source, second attempt.
This adds a new routine, pg_strong_random() for generating random bytes,
for use in both frontend and backend. At the moment, it's only used in
the backend, but the upcoming SCRAM authentication patches need strong
random numbers in libpq as well.
pg_strong_random() is based on, and replaces, the existing implementation
in pgcrypto. It can acquire strong random numbers from a number of sources,
depending on what's available:
- OpenSSL RAND_bytes(), if built with OpenSSL
- On Windows, the native cryptographic functions are used
- /dev/urandom
Unlike the current pgcrypto function, the source is chosen by configure.
That makes it easier to test different implementations, and ensures that
we don't accidentally fall back to a less secure implementation, if the
primary source fails. All of those methods are quite reliable, it would be
pretty surprising for them to fail, so we'd rather find out by failing
hard.
If no strong random source is available, we fall back to using erand48(),
seeded from current timestamp, like PostmasterRandom() was. That isn't
cryptographically secure, but allows us to still work on platforms that
don't have any of the above stronger sources. Because it's not very secure,
the built-in implementation is only used if explicitly requested with
--disable-strong-random.
This replaces the more complicated Fortuna algorithm we used to have in
pgcrypto, which is unfortunate, but all modern platforms have /dev/urandom,
so it doesn't seem worth the maintenance effort to keep that. pgcrypto
functions that require strong random numbers will be disabled with
--disable-strong-random.
Original patch by Magnus Hagander, tons of further work by Michael Paquier
and me.
Discussion: https://www.postgresql.org/message-id/CAB7nPqRy3krN8quR9XujMVVHYtXJ0_60nqgVc6oUk8ygyVkZsA@mail.gmail.com
Discussion: https://www.postgresql.org/message-id/CAB7nPqRWkNYRRPJA7-cF+LfroYV10pvjdz6GNvxk-Eee9FypKA@mail.gmail.com
2016-12-05 12:42:59 +01:00
|
|
|
int32 MyCancelKey;
|
Install a "dead man switch" to allow the postmaster to detect cases where
a backend has done exit(0) or exit(1) without having disengaged itself
from shared memory. We are at risk for this whenever third-party code is
loaded into a backend, since such code might not know it's supposed to go
through proc_exit() instead. Also, it is reported that under Windows
there are ways to externally kill a process that cause the status code
returned to the postmaster to be indistinguishable from a voluntary exit
(thank you, Microsoft). If this does happen then the system is probably
hosed --- for instance, the dead session might still be holding locks.
So the best recovery method is to treat this like a backend crash.
The dead man switch is armed for a particular child process when it
acquires a regular PGPROC, and disarmed when the PGPROC is released;
these should be the first and last touches of shared memory resources
in a backend, or close enough anyway. This choice means there is no
coverage for auxiliary processes, but I doubt we need that, since they
shouldn't be executing any user-provided code anyway.
This patch also improves the management of the EXEC_BACKEND
ShmemBackendArray array a bit, by reducing search costs.
Although this problem is of long standing, the lack of field complaints
seems to mean it's not critical enough to risk back-patching; at least
not till we get some more testing of this mechanism.
2009-05-05 21:59:00 +02:00
|
|
|
int MyPMChildSlot;
|
1998-07-09 05:29:11 +02:00
|
|
|
|
2015-01-14 18:45:22 +01:00
|
|
|
/*
|
|
|
|
* MyLatch points to the latch that should be used for signal handling by the
|
|
|
|
* current process. It will either point to a process local latch if the
|
|
|
|
* current process does not have a PGPROC entry in that moment, or to
|
|
|
|
* PGPROC->procLatch if it has. Thus it can always be used in signal handlers,
|
|
|
|
* without checking for its existence.
|
|
|
|
*/
|
|
|
|
struct Latch *MyLatch;
|
|
|
|
|
2005-07-04 06:51:52 +02:00
|
|
|
/*
|
|
|
|
* DataDir is the absolute path to the top level of the PGDATA directory tree.
|
|
|
|
* Except during early startup, this is also the server's working directory;
|
|
|
|
* most code therefore can simply use relative paths and not reference DataDir
|
|
|
|
* explicitly.
|
|
|
|
*/
|
1998-10-16 08:05:18 +02:00
|
|
|
char *DataDir = NULL;
|
2002-09-04 22:31:48 +02:00
|
|
|
|
2018-04-07 23:45:39 +02:00
|
|
|
/*
|
2018-05-23 16:59:55 +02:00
|
|
|
* Mode of the data directory. The default is 0700 but it may be changed in
|
2018-04-07 23:45:39 +02:00
|
|
|
* checkDataDir() to 0750 if the data directory actually has that mode.
|
|
|
|
*/
|
|
|
|
int data_directory_mode = PG_DIR_MODE_OWNER;
|
|
|
|
|
2004-05-28 07:13:32 +02:00
|
|
|
char OutputFileName[MAXPGPATH]; /* debugging output file */
|
2001-10-21 05:25:36 +02:00
|
|
|
|
2004-05-28 07:13:32 +02:00
|
|
|
char my_exec_path[MAXPGPATH]; /* full path to my executable */
|
|
|
|
char pkglib_path[MAXPGPATH]; /* full path to lib directory */
|
|
|
|
|
|
|
|
#ifdef EXEC_BACKEND
|
|
|
|
char postgres_exec_path[MAXPGPATH]; /* full path to backend */
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2004-05-28 07:13:32 +02:00
|
|
|
/* note: currently this is not valid in backend processes */
|
|
|
|
#endif
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2024-03-03 18:38:22 +01:00
|
|
|
ProcNumber MyProcNumber = INVALID_PROC_NUMBER;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2024-03-03 18:38:22 +01:00
|
|
|
ProcNumber ParallelLeaderProcNumber = INVALID_PROC_NUMBER;
|
Improve the situation for parallel query versus temp relations.
Transmit the leader's temp-namespace state to workers. This is important
because without it, the workers do not really have the same search path
as the leader. For example, there is no good reason (and no extant code
either) to prevent a worker from executing a temp function that the
leader created previously; but as things stood it would fail to find the
temp function, and then either fail or execute the wrong function entirely.
We still prohibit a worker from creating a temp namespace on its own.
In effect, a worker can only see the session's temp namespace if the leader
had created it before starting the worker, which seems like the right
semantics.
Also, transmit the leader's BackendId to workers, and arrange for workers
to use that when determining the physical file path of a temp relation
belonging to their session. While the original intent was to prevent such
accesses entirely, there were a number of holes in that, notably in places
like dbsize.c which assume they can safely access temp rels of other
sessions anyway. We might as well get this right, as a small down payment
on someday allowing workers to access the leader's temp tables. (With
this change, directly using "MyBackendId" as a relation or buffer backend
ID is deprecated; you should use BackendIdForTempRelations() instead.
I left a couple of such uses alone though, as they're not going to be
reachable in parallel workers until we do something about localbuf.c.)
Move the thou-shalt-not-access-thy-leader's-temp-tables prohibition down
into localbuf.c, which is where it actually matters, instead of having it
in relation_open(). This amounts to recognizing that access to temp
tables' catalog entries is perfectly safe in a worker, it's only the data
in local buffers that is problematic.
Having done all that, we can get rid of the test in has_parallel_hazard()
that says that use of a temp table's rowtype is unsafe in parallel workers.
That test was unduly expensive, and if we really did need such a
prohibition, that was not even close to being a bulletproof guard for it.
(For example, any user-defined function executed in a parallel worker
might have attempted such access.)
2016-06-10 02:16:11 +02:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
Oid MyDatabaseId = InvalidOid;
|
|
|
|
|
2004-06-18 08:14:31 +02:00
|
|
|
Oid MyDatabaseTableSpace = InvalidOid;
|
|
|
|
|
Add support event triggers on authenticated login
This commit introduces trigger on login event, allowing to fire some actions
right on the user connection. This can be useful for logging or connection
check purposes as well as for some personalization of environment. Usage
details are described in the documentation included, but shortly usage is
the same as for other triggers: create function returning event_trigger and
then create event trigger on login event.
In order to prevent the connection time overhead when there are no triggers
the commit introduces pg_database.dathasloginevt flag, which indicates database
has active login triggers. This flag is set by CREATE/ALTER EVENT TRIGGER
command, and unset at connection time when no active triggers found.
Author: Konstantin Knizhnik, Mikhail Gribkov
Discussion: https://postgr.es/m/0d46d29f-4558-3af9-9c85-7774e14a7709%40postgrespro.ru
Reviewed-by: Pavel Stehule, Takayuki Tsunakawa, Greg Nancarrow, Ivan Panchenko
Reviewed-by: Daniel Gustafsson, Teodor Sigaev, Robert Haas, Andres Freund
Reviewed-by: Tom Lane, Andrey Sokolov, Zhihong Yu, Sergey Shinderuk
Reviewed-by: Gregory Stark, Nikita Malakhov, Ted Yu
2023-10-16 02:16:55 +02:00
|
|
|
bool MyDatabaseHasLoginEventTriggers = false;
|
|
|
|
|
2005-07-04 06:51:52 +02:00
|
|
|
/*
|
|
|
|
* DatabasePath is the path (relative to DataDir) of my database's
|
|
|
|
* primary directory, ie, its directory in the default tablespace.
|
|
|
|
*/
|
|
|
|
char *DatabasePath = NULL;
|
|
|
|
|
2004-01-28 22:02:40 +01:00
|
|
|
pid_t PostmasterPid = 0;
|
2004-01-26 23:59:54 +01:00
|
|
|
|
2004-01-28 22:02:40 +01:00
|
|
|
/*
|
|
|
|
* IsPostmasterEnvironment is true in a postmaster process and any postmaster
|
|
|
|
* child process; it is false in a standalone process (bootstrap or
|
|
|
|
* standalone backend). IsUnderPostmaster is true in postmaster child
|
|
|
|
* processes. Note that "child process" includes all children, not only
|
|
|
|
* regular backends. These should be set correctly as early as possible
|
|
|
|
* in the execution of a process, so that error handling will do the right
|
|
|
|
* things if an error should occur during process initialization.
|
|
|
|
*
|
|
|
|
* These are initialized for the bootstrap/standalone case.
|
|
|
|
*/
|
2003-05-28 19:25:02 +02:00
|
|
|
bool IsPostmasterEnvironment = false;
|
1996-07-09 08:22:35 +02:00
|
|
|
bool IsUnderPostmaster = false;
|
2011-04-25 18:00:21 +02:00
|
|
|
bool IsBinaryUpgrade = false;
|
1996-07-09 08:22:35 +02:00
|
|
|
|
2003-05-28 20:19:09 +02:00
|
|
|
bool ExitOnAnyError = false;
|
|
|
|
|
Make ISO date style (e.g. "2000-02-16 09:33") the default.
Implement "date/time grand unification".
Transform datetime and timespan into timestamp and interval.
Deprecate datetime and timespan, though translate to new types in gram.y.
Transform all datetime and timespan catalog entries into new types.
Make "INTERVAL" reserved word allowed as a column identifier in gram.y.
Remove dt.h, dt.c files, and retarget datetime.h, datetime.c as utility
routines for all date/time types.
date.{h,c} now deals with date, time types.
timestamp.{h,c} now deals with timestamp, interval types.
nabstime.{h,c} now deals with abstime, reltime, tinterval types.
Make NUMERIC a known native type for purposes of type coersion. Not tested.
2000-02-16 18:25:49 +01:00
|
|
|
int DateStyle = USE_ISO_DATES;
|
2003-07-29 02:03:19 +02:00
|
|
|
int DateOrder = DATEORDER_MDY;
|
2008-11-09 01:28:35 +01:00
|
|
|
int IntervalStyle = INTSTYLE_POSTGRES;
|
1997-01-26 16:32:28 +01:00
|
|
|
|
2000-05-31 02:28:42 +02:00
|
|
|
bool enableFsync = true;
|
1999-03-17 23:53:31 +01:00
|
|
|
bool allowSystemTableMods = false;
|
2020-07-03 01:34:54 +02:00
|
|
|
int work_mem = 4096;
|
2022-02-17 03:41:52 +01:00
|
|
|
double hash_mem_multiplier = 2.0;
|
2020-07-03 01:34:54 +02:00
|
|
|
int maintenance_work_mem = 65536;
|
Support parallel btree index builds.
To make this work, tuplesort.c and logtape.c must also support
parallelism, so this patch adds that infrastructure and then applies
it to the particular case of parallel btree index builds. Testing
to date shows that this can often be 2-3x faster than a serial
index build.
The model for deciding how many workers to use is fairly primitive
at present, but it's better than not having the feature. We can
refine it as we get more experience.
Peter Geoghegan with some help from Rushabh Lathia. While Heikki
Linnakangas is not an author of this patch, he wrote other patches
without which this feature would not have been possible, and
therefore the release notes should possibly credit him as an author
of this feature. Reviewed by Claudio Freire, Heikki Linnakangas,
Thomas Munro, Tels, Amit Kapila, me.
Discussion: http://postgr.es/m/CAM3SWZQKM=Pzc=CAHzRixKjp2eO5Q0Jg1SoFQqeXFQ647JiwqQ@mail.gmail.com
Discussion: http://postgr.es/m/CAH2-Wz=AxWqDoVvGU7dq856S4r6sJAj6DBn7VMtigkB33N5eyg@mail.gmail.com
2018-02-02 19:25:55 +01:00
|
|
|
int max_parallel_maintenance_workers = 2;
|
2004-05-30 00:48:23 +02:00
|
|
|
|
2007-04-16 20:30:04 +02:00
|
|
|
/*
|
2013-01-02 16:01:14 +01:00
|
|
|
* Primary determinants of sizes of shared-memory structures.
|
|
|
|
*
|
|
|
|
* MaxBackends is computed by PostmasterMain after modules have had a chance to
|
|
|
|
* register background workers.
|
2007-04-16 20:30:04 +02:00
|
|
|
*/
|
2022-10-31 04:44:48 +01:00
|
|
|
int NBuffers = 16384;
|
|
|
|
int MaxConnections = 100;
|
2016-12-05 16:53:21 +01:00
|
|
|
int max_worker_processes = 8;
|
2016-12-02 13:42:58 +01:00
|
|
|
int max_parallel_workers = 8;
|
2013-01-02 16:01:14 +01:00
|
|
|
int MaxBackends = 0;
|
2004-02-06 20:36:18 +01:00
|
|
|
|
2023-04-07 01:40:31 +02:00
|
|
|
/* GUC parameters for vacuum */
|
|
|
|
int VacuumBufferUsageLimit = 256;
|
|
|
|
|
|
|
|
int VacuumCostPageHit = 1;
|
2021-01-28 00:11:13 +01:00
|
|
|
int VacuumCostPageMiss = 2;
|
2004-02-06 20:36:18 +01:00
|
|
|
int VacuumCostPageDirty = 20;
|
2019-03-10 20:05:25 +01:00
|
|
|
int VacuumCostLimit = 200;
|
2019-03-10 20:01:39 +01:00
|
|
|
double VacuumCostDelay = 0;
|
2004-02-10 04:42:45 +01:00
|
|
|
|
2020-02-05 20:59:29 +01:00
|
|
|
int64 VacuumPageHit = 0;
|
|
|
|
int64 VacuumPageMiss = 0;
|
|
|
|
int64 VacuumPageDirty = 0;
|
2011-11-25 16:10:46 +01:00
|
|
|
|
2004-02-10 04:42:45 +01:00
|
|
|
int VacuumCostBalance = 0; /* working state for vacuum */
|
2004-02-06 20:36:18 +01:00
|
|
|
bool VacuumCostActive = false;
|
Improve performance of subsystems on top of SLRU
More precisely, what we do here is make the SLRU cache sizes
configurable with new GUCs, so that sites with high concurrency and big
ranges of transactions in flight (resp. multixacts/subtransactions) can
benefit from bigger caches. In order for this to work with good
performance, two additional changes are made:
1. the cache is divided in "banks" (to borrow terminology from CPU
caches), and algorithms such as eviction buffer search only affect
one specific bank. This forestalls the problem that linear searching
for a specific buffer across the whole cache takes too long: we only
have to search the specific bank, whose size is small. This work is
authored by Andrey Borodin.
2. Change the locking regime for the SLRU banks, so that each bank uses
a separate LWLock. This allows for increased scalability. This work
is authored by Dilip Kumar. (A part of this was previously committed as
d172b717c6f4.)
Special care is taken so that the algorithms that can potentially
traverse more than one bank release one bank's lock before acquiring the
next. This should happen rarely, but particularly clog.c's group commit
feature needed code adjustment to cope with this. I (Álvaro) also added
lots of comments to make sure the design is sound.
The new GUCs match the names introduced by bcdfa5f2e2f2 in the
pg_stat_slru view.
The default values for these parameters are similar to the previous
sizes of each SLRU. commit_ts, clog and subtrans accept value 0, which
means to adjust by dividing shared_buffers by 512 (so 2MB for every 1GB
of shared_buffers), with a cap of 8MB. (A new slru.c function
SimpleLruAutotuneBuffers() was added to support this.) The cap was
previously 1MB for clog, so for sites with more than 512MB of shared
memory the total memory used increases, which is likely a good tradeoff.
However, other SLRUs (notably multixact ones) retain smaller sizes and
don't support a configured value of 0. These values based on
shared_buffers may need to be revisited, but that's an easy change.
There was some resistance to adding these new GUCs: it would be better
to adjust to memory pressure automatically somehow, for example by
stealing memory from shared_buffers (where the caches can grow and
shrink naturally). However, doing that seems to be a much larger
project and one which has made virtually no progress in several years,
and because this is such a pain point for so many users, here we take
the pragmatic approach.
Author: Andrey Borodin <x4mmm@yandex-team.ru>
Author: Dilip Kumar <dilipbalaut@gmail.com>
Reviewed-by: Amul Sul, Gilles Darold, Anastasia Lubennikova,
Ivan Lazarev, Robert Haas, Thomas Munro, Tomas Vondra,
Yura Sokolov, Васильев Дмитрий (Dmitry Vasiliev).
Discussion: https://postgr.es/m/2BEC2B3F-9B61-4C1D-9FB5-5FAB0F05EF86@yandex-team.ru
Discussion: https://postgr.es/m/CAFiTN-vzDvNz=ExGXz6gdyjtzGixKSqs0mKHMmaQ8sOSEFZ33A@mail.gmail.com
2024-02-28 17:05:31 +01:00
|
|
|
|
|
|
|
/* configurable SLRU buffer sizes */
|
|
|
|
int commit_timestamp_buffers = 0;
|
|
|
|
int multixact_member_buffers = 32;
|
|
|
|
int multixact_offset_buffers = 16;
|
|
|
|
int notify_buffers = 16;
|
|
|
|
int serializable_buffers = 32;
|
|
|
|
int subtransaction_buffers = 0;
|
|
|
|
int transaction_buffers = 0;
|