1996-10-31 08:10:14 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* miscadmin.h
|
2004-03-24 23:40:29 +01:00
|
|
|
* This file contains general postgres administration and initialization
|
1997-09-07 07:04:48 +02:00
|
|
|
* stuff that used to be spread out between the following files:
|
|
|
|
|
* globals.h global variables
|
|
|
|
|
* pdir.h directory path crud
|
|
|
|
|
* pinit.h postgres initialization
|
|
|
|
|
* pmod.h processing modes
|
2004-03-24 23:40:29 +01:00
|
|
|
* Over time, this has also become the preferred place for widely known
|
|
|
|
|
* resource-limitation stuff, such as work_mem and check_stack_depth().
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
2019-01-02 18:44:25 +01:00
|
|
|
* Portions Copyright (c) 1996-2019, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/include/miscadmin.h
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
|
|
|
|
* NOTES
|
2004-05-30 00:48:23 +02:00
|
|
|
* some of the information in this file should be moved to other files.
|
1996-10-31 08:10:14 +01:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef MISCADMIN_H
|
|
|
|
|
#define MISCADMIN_H
|
|
|
|
|
|
2017-06-06 03:53:41 +02:00
|
|
|
#include <signal.h>
|
|
|
|
|
|
2018-10-19 02:59:14 +02:00
|
|
|
#include "datatype/timestamp.h" /* for TimestampTZ */
|
2008-02-17 03:09:32 +01:00
|
|
|
#include "pgtime.h" /* for pg_time_t */
|
2007-08-03 01:39:45 +02:00
|
|
|
|
2002-05-05 02:03:29 +02:00
|
|
|
|
2013-08-28 20:08:13 +02:00
|
|
|
#define InvalidPid (-1)
|
|
|
|
|
|
2004-05-30 00:48:23 +02:00
|
|
|
|
2001-01-14 06:08:17 +01:00
|
|
|
/*****************************************************************************
|
2001-03-22 05:01:46 +01:00
|
|
|
* System interrupt and critical section handling
|
2001-01-14 06:08:17 +01:00
|
|
|
*
|
|
|
|
|
* There are two types of interrupts that a running backend needs to accept
|
|
|
|
|
* without messing up its state: QueryCancel (SIGINT) and ProcDie (SIGTERM).
|
|
|
|
|
* In both cases, we need to be able to clean up the current transaction
|
|
|
|
|
* gracefully, so we can't respond to the interrupt instantaneously ---
|
|
|
|
|
* there's no guarantee that internal data structures would be self-consistent
|
2014-05-06 18:12:18 +02:00
|
|
|
* if the code is interrupted at an arbitrary instant. Instead, the signal
|
2001-01-14 06:08:17 +01:00
|
|
|
* handlers set flags that are checked periodically during execution.
|
|
|
|
|
*
|
|
|
|
|
* The CHECK_FOR_INTERRUPTS() macro is called at strategically located spots
|
|
|
|
|
* where it is normally safe to accept a cancel or die interrupt. In some
|
|
|
|
|
* cases, we invoke CHECK_FOR_INTERRUPTS() inside low-level subroutines that
|
|
|
|
|
* might sometimes be called in contexts that do *not* want to allow a cancel
|
2001-01-19 23:08:47 +01:00
|
|
|
* or die interrupt. The HOLD_INTERRUPTS() and RESUME_INTERRUPTS() macros
|
|
|
|
|
* allow code to ensure that no cancel or die interrupt will be accepted,
|
2014-05-06 18:12:18 +02:00
|
|
|
* even if CHECK_FOR_INTERRUPTS() gets called in a subroutine. The interrupt
|
2002-01-02 00:16:22 +01:00
|
|
|
* will be held off until CHECK_FOR_INTERRUPTS() is done outside any
|
|
|
|
|
* HOLD_INTERRUPTS() ... RESUME_INTERRUPTS() section.
|
2001-01-14 06:08:17 +01:00
|
|
|
*
|
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
|
|
|
* There is also a mechanism to prevent query cancel interrupts, while still
|
|
|
|
|
* allowing die interrupts: HOLD_CANCEL_INTERRUPTS() and
|
|
|
|
|
* RESUME_CANCEL_INTERRUPTS().
|
|
|
|
|
*
|
2001-01-14 06:08:17 +01:00
|
|
|
* Special mechanisms are used to let an interrupt be accepted when we are
|
2001-09-29 06:02:27 +02:00
|
|
|
* waiting for a lock or when we are waiting for command input (but, of
|
2014-05-06 18:12:18 +02:00
|
|
|
* course, only if the interrupt holdoff counter is zero). See the
|
2001-01-14 06:08:17 +01:00
|
|
|
* related code for details.
|
|
|
|
|
*
|
2011-12-09 10:37:21 +01:00
|
|
|
* A lost connection is handled similarly, although the loss of connection
|
|
|
|
|
* does not raise a signal, but is detected when we fail to write to the
|
|
|
|
|
* socket. If there was a signal for a broken connection, we could make use of
|
|
|
|
|
* it by setting ClientConnectionLost in the signal handler.
|
|
|
|
|
*
|
2001-01-19 23:08:47 +01:00
|
|
|
* A related, but conceptually distinct, mechanism is the "critical section"
|
|
|
|
|
* mechanism. A critical section not only holds off cancel/die interrupts,
|
2003-07-27 19:10:07 +02:00
|
|
|
* but causes any ereport(ERROR) or ereport(FATAL) to become ereport(PANIC)
|
2014-05-06 18:12:18 +02:00
|
|
|
* --- that is, a system-wide reset is forced. Needless to say, only really
|
2003-08-04 02:43:34 +02:00
|
|
|
* *critical* code should be marked as a critical section! Currently, this
|
2003-07-27 19:10:07 +02:00
|
|
|
* mechanism is only used for XLOG-related code.
|
2001-01-19 23:08:47 +01:00
|
|
|
*
|
2001-01-14 06:08:17 +01:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
/* in globals.c */
|
|
|
|
|
/* these are marked volatile because they are set by signal handlers: */
|
2018-09-27 00:47:20 +02:00
|
|
|
extern PGDLLIMPORT volatile sig_atomic_t InterruptPending;
|
|
|
|
|
extern PGDLLIMPORT volatile sig_atomic_t QueryCancelPending;
|
|
|
|
|
extern PGDLLIMPORT volatile sig_atomic_t ProcDiePending;
|
|
|
|
|
extern PGDLLIMPORT volatile sig_atomic_t IdleInTransactionSessionTimeoutPending;
|
2017-06-06 03:53:41 +02:00
|
|
|
extern PGDLLIMPORT volatile sig_atomic_t ConfigReloadPending;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2018-09-27 00:47:20 +02:00
|
|
|
extern PGDLLIMPORT volatile sig_atomic_t ClientConnectionLost;
|
2011-12-09 10:37:21 +01:00
|
|
|
|
2001-01-14 06:08:17 +01:00
|
|
|
/* these are marked volatile because they are examined by signal handlers: */
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT volatile uint32 InterruptHoldoffCount;
|
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
|
|
|
extern PGDLLIMPORT volatile uint32 QueryCancelHoldoffCount;
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT volatile uint32 CritSectionCount;
|
2001-01-14 06:08:17 +01:00
|
|
|
|
2004-03-24 23:40:29 +01:00
|
|
|
/* in tcop/postgres.c */
|
2001-01-14 06:08:17 +01:00
|
|
|
extern void ProcessInterrupts(void);
|
|
|
|
|
|
2004-02-08 23:28:57 +01:00
|
|
|
#ifndef WIN32
|
2004-05-30 00:48:23 +02:00
|
|
|
|
2001-01-14 06:08:17 +01:00
|
|
|
#define CHECK_FOR_INTERRUPTS() \
|
2004-01-09 22:08:50 +01:00
|
|
|
do { \
|
|
|
|
|
if (InterruptPending) \
|
|
|
|
|
ProcessInterrupts(); \
|
|
|
|
|
} while(0)
|
2004-08-29 07:07:03 +02:00
|
|
|
#else /* WIN32 */
|
2004-05-30 00:48:23 +02:00
|
|
|
|
2004-02-08 23:28:57 +01:00
|
|
|
#define CHECK_FOR_INTERRUPTS() \
|
|
|
|
|
do { \
|
2005-10-25 17:15:16 +02:00
|
|
|
if (UNBLOCKED_SIGNAL_QUEUE()) \
|
|
|
|
|
pgwin32_dispatch_queued_signals(); \
|
2004-02-08 23:28:57 +01:00
|
|
|
if (InterruptPending) \
|
|
|
|
|
ProcessInterrupts(); \
|
2004-02-10 04:42:45 +01:00
|
|
|
} while(0)
|
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 /* WIN32 */
|
2004-02-08 23:28:57 +01:00
|
|
|
|
2001-01-14 06:08:17 +01:00
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define HOLD_INTERRUPTS() (InterruptHoldoffCount++)
|
2001-01-19 23:08:47 +01:00
|
|
|
|
|
|
|
|
#define RESUME_INTERRUPTS() \
|
2004-01-09 22:08:50 +01:00
|
|
|
do { \
|
|
|
|
|
Assert(InterruptHoldoffCount > 0); \
|
|
|
|
|
InterruptHoldoffCount--; \
|
|
|
|
|
} while(0)
|
2001-01-19 23:08:47 +01:00
|
|
|
|
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
|
|
|
#define HOLD_CANCEL_INTERRUPTS() (QueryCancelHoldoffCount++)
|
|
|
|
|
|
|
|
|
|
#define RESUME_CANCEL_INTERRUPTS() \
|
|
|
|
|
do { \
|
|
|
|
|
Assert(QueryCancelHoldoffCount > 0); \
|
|
|
|
|
QueryCancelHoldoffCount--; \
|
|
|
|
|
} while(0)
|
|
|
|
|
|
2001-03-22 05:01:46 +01:00
|
|
|
#define START_CRIT_SECTION() (CritSectionCount++)
|
2001-01-14 06:08:17 +01:00
|
|
|
|
|
|
|
|
#define END_CRIT_SECTION() \
|
2004-01-09 22:08:50 +01:00
|
|
|
do { \
|
|
|
|
|
Assert(CritSectionCount > 0); \
|
|
|
|
|
CritSectionCount--; \
|
|
|
|
|
} while(0)
|
|
|
|
|
|
2004-01-26 23:59:54 +01:00
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/*****************************************************************************
|
1997-09-07 07:04:48 +02:00
|
|
|
* globals.h -- *
|
1996-10-31 08:10:14 +01:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* from utils/init/globals.c
|
|
|
|
|
*/
|
2016-06-03 19:50:51 +02:00
|
|
|
extern PGDLLIMPORT pid_t PostmasterPid;
|
2016-11-26 16:29:18 +01:00
|
|
|
extern PGDLLIMPORT bool IsPostmasterEnvironment;
|
2009-01-05 03:27:45 +01:00
|
|
|
extern PGDLLIMPORT bool IsUnderPostmaster;
|
2016-11-26 16:29:18 +01:00
|
|
|
extern PGDLLIMPORT bool IsBackgroundWorker;
|
2014-08-26 15:25:18 +02:00
|
|
|
extern PGDLLIMPORT bool IsBinaryUpgrade;
|
2003-05-28 20:19:09 +02:00
|
|
|
|
2017-12-05 15:23:57 +01:00
|
|
|
extern PGDLLIMPORT bool ExitOnAnyError;
|
2003-05-28 20:19:09 +02:00
|
|
|
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT char *DataDir;
|
2018-04-07 23:45:39 +02:00
|
|
|
extern PGDLLIMPORT int data_directory_mode;
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT int NBuffers;
|
2017-12-05 15:23:57 +01:00
|
|
|
extern PGDLLIMPORT int MaxBackends;
|
|
|
|
|
extern PGDLLIMPORT int MaxConnections;
|
|
|
|
|
extern PGDLLIMPORT int max_worker_processes;
|
2018-02-09 21:54:45 +01:00
|
|
|
extern PGDLLIMPORT int max_parallel_workers;
|
2004-05-30 00:48:23 +02:00
|
|
|
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT int MyProcPid;
|
2008-02-17 03:09:32 +01:00
|
|
|
extern PGDLLIMPORT pg_time_t MyStartTime;
|
2018-10-19 02:59:14 +02:00
|
|
|
extern PGDLLIMPORT TimestampTz MyStartTimestamp;
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT struct Port *MyProcPort;
|
2015-01-14 18:45:22 +01:00
|
|
|
extern PGDLLIMPORT struct Latch *MyLatch;
|
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
|
|
|
extern 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
|
|
|
extern int MyPMChildSlot;
|
1998-07-09 05:29:11 +02:00
|
|
|
|
1997-09-08 04:41:22 +02:00
|
|
|
extern char OutputFileName[];
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT char my_exec_path[];
|
2004-05-17 16:35:34 +02:00
|
|
|
extern char pkglib_path[];
|
2004-08-29 07:07:03 +02:00
|
|
|
|
2004-05-28 07:13:32 +02:00
|
|
|
#ifdef EXEC_BACKEND
|
|
|
|
|
extern char postgres_exec_path[];
|
|
|
|
|
#endif
|
1996-10-31 08:10:14 +01:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* done in storage/backendid.h for now.
|
|
|
|
|
*
|
|
|
|
|
* extern BackendId MyBackendId;
|
|
|
|
|
*/
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT Oid MyDatabaseId;
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT Oid MyDatabaseTableSpace;
|
2004-06-18 08:14:31 +02:00
|
|
|
|
2003-07-29 02:03:19 +02:00
|
|
|
/*
|
|
|
|
|
* Date/Time Configuration
|
1997-03-25 09:11:24 +01:00
|
|
|
*
|
2003-07-29 02:03:19 +02:00
|
|
|
* DateStyle defines the output formatting choice for date/time types:
|
|
|
|
|
* USE_POSTGRES_DATES specifies traditional Postgres format
|
|
|
|
|
* USE_ISO_DATES specifies ISO-compliant format
|
|
|
|
|
* USE_SQL_DATES specifies Oracle/Ingres-compliant format
|
|
|
|
|
* USE_GERMAN_DATES specifies German-style dd.mm/yyyy
|
1997-03-25 09:11:24 +01:00
|
|
|
*
|
2003-07-29 02:03:19 +02:00
|
|
|
* DateOrder defines the field order to be assumed when reading an
|
|
|
|
|
* ambiguous date (anything not in YYYY-MM-DD format, with a four-digit
|
|
|
|
|
* year field first, is taken to be ambiguous):
|
|
|
|
|
* DATEORDER_YMD specifies field order yy-mm-dd
|
|
|
|
|
* DATEORDER_DMY specifies field order dd-mm-yy ("European" convention)
|
|
|
|
|
* DATEORDER_MDY specifies field order mm-dd-yy ("US" convention)
|
1997-03-25 09:11:24 +01:00
|
|
|
*
|
2003-07-29 02:03:19 +02:00
|
|
|
* In the Postgres and SQL DateStyles, DateOrder also selects output field
|
|
|
|
|
* order: day comes before month in DMY style, else month comes before day.
|
|
|
|
|
*
|
|
|
|
|
* The user-visible "DateStyle" run-time parameter subsumes both of these.
|
1997-03-18 17:36:50 +01:00
|
|
|
*/
|
|
|
|
|
|
2003-07-29 02:03:19 +02:00
|
|
|
/* valid DateStyle values */
|
1997-09-07 07:04:48 +02:00
|
|
|
#define USE_POSTGRES_DATES 0
|
|
|
|
|
#define USE_ISO_DATES 1
|
|
|
|
|
#define USE_SQL_DATES 2
|
1997-12-05 00:58:01 +01:00
|
|
|
#define USE_GERMAN_DATES 3
|
2007-03-01 15:52:04 +01:00
|
|
|
#define USE_XSD_DATES 4
|
1997-03-25 09:11:24 +01:00
|
|
|
|
2003-07-29 02:03:19 +02:00
|
|
|
/* valid DateOrder values */
|
|
|
|
|
#define DATEORDER_YMD 0
|
|
|
|
|
#define DATEORDER_DMY 1
|
|
|
|
|
#define DATEORDER_MDY 2
|
|
|
|
|
|
2014-02-16 18:37:07 +01:00
|
|
|
extern PGDLLIMPORT int DateStyle;
|
|
|
|
|
extern PGDLLIMPORT int DateOrder;
|
2009-06-11 16:49:15 +02:00
|
|
|
|
2008-11-09 01:28:35 +01:00
|
|
|
/*
|
|
|
|
|
* IntervalStyles
|
2009-06-11 16:49:15 +02:00
|
|
|
* INTSTYLE_POSTGRES Like Postgres < 8.4 when DateStyle = 'iso'
|
|
|
|
|
* INTSTYLE_POSTGRES_VERBOSE Like Postgres < 8.4 when DateStyle != 'iso'
|
|
|
|
|
* INTSTYLE_SQL_STANDARD SQL standard interval literals
|
|
|
|
|
* INTSTYLE_ISO_8601 ISO-8601-basic formatted intervals
|
2008-11-09 01:28:35 +01:00
|
|
|
*/
|
2008-11-11 03:42:33 +01:00
|
|
|
#define INTSTYLE_POSTGRES 0
|
|
|
|
|
#define INTSTYLE_POSTGRES_VERBOSE 1
|
|
|
|
|
#define INTSTYLE_SQL_STANDARD 2
|
|
|
|
|
#define INTSTYLE_ISO_8601 3
|
2008-11-09 01:28:35 +01:00
|
|
|
|
2014-02-16 18:37:07 +01:00
|
|
|
extern PGDLLIMPORT int IntervalStyle;
|
2003-07-29 02:03:19 +02:00
|
|
|
|
|
|
|
|
#define MAXTZLEN 10 /* max TZ name len, not counting tr. null */
|
|
|
|
|
|
2000-05-31 02:28:42 +02:00
|
|
|
extern bool enableFsync;
|
2017-12-05 15:23:57 +01:00
|
|
|
extern PGDLLIMPORT bool allowSystemTableMods;
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT int work_mem;
|
|
|
|
|
extern PGDLLIMPORT int maintenance_work_mem;
|
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
|
|
|
extern PGDLLIMPORT int max_parallel_maintenance_workers;
|
2004-02-06 20:36:18 +01:00
|
|
|
|
|
|
|
|
extern int VacuumCostPageHit;
|
|
|
|
|
extern int VacuumCostPageMiss;
|
|
|
|
|
extern int VacuumCostPageDirty;
|
|
|
|
|
extern int VacuumCostLimit;
|
2019-03-10 20:01:39 +01:00
|
|
|
extern double VacuumCostDelay;
|
2004-02-10 04:42:45 +01:00
|
|
|
|
2011-11-25 16:10:46 +01:00
|
|
|
extern int VacuumPageHit;
|
|
|
|
|
extern int VacuumPageMiss;
|
|
|
|
|
extern int VacuumPageDirty;
|
|
|
|
|
|
2004-02-10 04:42:45 +01:00
|
|
|
extern int VacuumCostBalance;
|
2004-08-29 07:07:03 +02:00
|
|
|
extern bool VacuumCostActive;
|
1997-08-14 18:11:41 +02:00
|
|
|
|
Skip full index scan during cleanup of B-tree indexes when possible
Vacuum of index consists from two stages: multiple (zero of more) ambulkdelete
calls and one amvacuumcleanup call. When workload on particular table
is append-only, then autovacuum isn't intended to touch this table. However,
user may run vacuum manually in order to fill visibility map and get benefits
of index-only scans. Then ambulkdelete wouldn't be called for indexes
of such table (because no heap tuples were deleted), only amvacuumcleanup would
be called In this case, amvacuumcleanup would perform full index scan for
two objectives: put recyclable pages into free space map and update index
statistics.
This patch allows btvacuumclanup to skip full index scan when two conditions
are satisfied: no pages are going to be put into free space map and index
statistics isn't stalled. In order to check first condition, we store
oldest btpo_xact in the meta-page. When it's precedes RecentGlobalXmin, then
there are some recyclable pages. In order to check second condition we store
number of heap tuples observed during previous full index scan by cleanup.
If fraction of newly inserted tuples is less than
vacuum_cleanup_index_scale_factor, then statistics isn't considered to be
stalled. vacuum_cleanup_index_scale_factor can be defined as both reloption and GUC (default).
This patch bumps B-tree meta-page version. Upgrade of meta-page is performed
"on the fly": during VACUUM meta-page is rewritten with new version. No special
handling in pg_upgrade is required.
Author: Masahiko Sawada, Alexander Korotkov
Review by: Peter Geoghegan, Kyotaro Horiguchi, Alexander Korotkov, Yura Sokolov
Discussion: https://www.postgresql.org/message-id/flat/CAD21AoAX+d2oD_nrd9O2YkpzHaFr=uQeGr9s1rKC3O4ENc568g@mail.gmail.com
2018-04-04 18:29:00 +02:00
|
|
|
extern double vacuum_cleanup_index_scale_factor;
|
|
|
|
|
|
2000-05-31 02:28:42 +02:00
|
|
|
|
2004-03-24 23:40:29 +01:00
|
|
|
/* in tcop/postgres.c */
|
Do stack-depth checking in all postmaster children.
We used to only initialize the stack base pointer when starting up a regular
backend, not in other processes. In particular, autovacuum workers can run
arbitrary user code, and without stack-depth checking, infinite recursion
in e.g an index expression will bring down the whole cluster.
The comment about PL/Java using set_stack_base() is not yet true. As the
code stands, PL/java still modifies the stack_base_ptr variable directly.
However, it's been discussed in the PL/Java mailing list that it should be
changed to use the function, because PL/Java is currently oblivious to the
register stack used on Itanium. There's another issues with PL/Java, namely
that the stack base pointer it sets is not really the base of the stack, it
could be something close to the bottom of the stack. That's a separate issue
that might need some further changes to this code, but that's a different
story.
Backpatch to all supported releases.
2012-04-08 17:28:12 +02:00
|
|
|
|
|
|
|
|
#if defined(__ia64__) || defined(__ia64)
|
|
|
|
|
typedef struct
|
|
|
|
|
{
|
|
|
|
|
char *stack_base_ptr;
|
|
|
|
|
char *register_stack_base_ptr;
|
|
|
|
|
} pg_stack_base_t;
|
|
|
|
|
#else
|
|
|
|
|
typedef char *pg_stack_base_t;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
extern pg_stack_base_t set_stack_base(void);
|
|
|
|
|
extern void restore_stack_base(pg_stack_base_t base);
|
2004-03-24 23:40:29 +01:00
|
|
|
extern void check_stack_depth(void);
|
2015-10-02 20:51:58 +02:00
|
|
|
extern bool stack_is_too_deep(void);
|
2004-03-24 23:40:29 +01:00
|
|
|
|
2017-06-06 03:53:41 +02:00
|
|
|
extern void PostgresSigHupHandler(SIGNAL_ARGS);
|
|
|
|
|
|
Allow read only connections during recovery, known as Hot Standby.
Enabled by recovery_connections = on (default) and forcing archive recovery using a recovery.conf. Recovery processing now emulates the original transactions as they are replayed, providing full locking and MVCC behaviour for read only queries. Recovery must enter consistent state before connections are allowed, so there is a delay, typically short, before connections succeed. Replay of recovering transactions can conflict and in some cases deadlock with queries during recovery; these result in query cancellation after max_standby_delay seconds have expired. Infrastructure changes have minor effects on normal running, though introduce four new types of WAL record.
New test mode "make standbycheck" allows regression tests of static command behaviour on a standby server while in recovery. Typical and extreme dynamic behaviours have been checked via code inspection and manual testing. Few port specific behaviours have been utilised, though primary testing has been on Linux only so far.
This commit is the basic patch. Additional changes will follow in this release to enhance some aspects of behaviour, notably improved handling of conflicts, deadlock detection and query cancellation. Changes to VACUUM FULL are also required.
Simon Riggs, with significant and lengthy review by Heikki Linnakangas, including streamlined redesign of snapshot creation and two-phase commit.
Important contributions from Florian Pflug, Mark Kirkwood, Merlin Moncure, Greg Stark, Gianni Ciolli, Gabriele Bartolini, Hannu Krosing, Robert Haas, Tatsuo Ishii, Hiroyuki Yamada plus support and feedback from many other community members.
2009-12-19 02:32:45 +01:00
|
|
|
/* in tcop/utility.c */
|
2010-02-20 22:24:02 +01:00
|
|
|
extern void PreventCommandIfReadOnly(const char *cmdname);
|
Create an infrastructure for parallel computation in PostgreSQL.
This does four basic things. First, it provides convenience routines
to coordinate the startup and shutdown of parallel workers. Second,
it synchronizes various pieces of state (e.g. GUCs, combo CID
mappings, transaction snapshot) from the parallel group leader to the
worker processes. Third, it prohibits various operations that would
result in unsafe changes to that state while parallelism is active.
Finally, it propagates events that would result in an ErrorResponse,
NoticeResponse, or NotifyResponse message being sent to the client
from the parallel workers back to the master, from which they can then
be sent on to the client.
Robert Haas, Amit Kapila, Noah Misch, Rushabh Lathia, Jeevan Chalke.
Suggestions and review from Andres Freund, Heikki Linnakangas, Noah
Misch, Simon Riggs, Euler Taveira, and Jim Nasby.
2015-04-30 21:02:14 +02:00
|
|
|
extern void PreventCommandIfParallelMode(const char *cmdname);
|
2010-02-20 22:24:02 +01:00
|
|
|
extern void PreventCommandDuringRecovery(const char *cmdname);
|
Allow read only connections during recovery, known as Hot Standby.
Enabled by recovery_connections = on (default) and forcing archive recovery using a recovery.conf. Recovery processing now emulates the original transactions as they are replayed, providing full locking and MVCC behaviour for read only queries. Recovery must enter consistent state before connections are allowed, so there is a delay, typically short, before connections succeed. Replay of recovering transactions can conflict and in some cases deadlock with queries during recovery; these result in query cancellation after max_standby_delay seconds have expired. Infrastructure changes have minor effects on normal running, though introduce four new types of WAL record.
New test mode "make standbycheck" allows regression tests of static command behaviour on a standby server while in recovery. Typical and extreme dynamic behaviours have been checked via code inspection and manual testing. Few port specific behaviours have been utilised, though primary testing has been on Linux only so far.
This commit is the basic patch. Additional changes will follow in this release to enhance some aspects of behaviour, notably improved handling of conflicts, deadlock detection and query cancellation. Changes to VACUUM FULL are also required.
Simon Riggs, with significant and lengthy review by Heikki Linnakangas, including streamlined redesign of snapshot creation and two-phase commit.
Important contributions from Florian Pflug, Mark Kirkwood, Merlin Moncure, Greg Stark, Gianni Ciolli, Gabriele Bartolini, Hannu Krosing, Robert Haas, Tatsuo Ishii, Hiroyuki Yamada plus support and feedback from many other community members.
2009-12-19 02:32:45 +01:00
|
|
|
|
|
|
|
|
/* in utils/misc/guc.c */
|
2010-02-26 03:01:40 +01:00
|
|
|
extern int trace_recovery_messages;
|
2010-06-17 19:44:40 +02:00
|
|
|
extern int trace_recovery(int trace_level);
|
2004-03-24 23:40:29 +01:00
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/*****************************************************************************
|
1997-09-07 07:04:48 +02:00
|
|
|
* pdir.h -- *
|
2014-05-06 18:12:18 +02:00
|
|
|
* POSTGRES directory path definitions. *
|
1996-10-31 08:10:14 +01:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
/* flags to be OR'd to form sec_context */
|
|
|
|
|
#define SECURITY_LOCAL_USERID_CHANGE 0x0001
|
|
|
|
|
#define SECURITY_RESTRICTED_OPERATION 0x0002
|
2015-10-05 03:05:08 +02:00
|
|
|
#define SECURITY_NOFORCE_RLS 0x0004
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
|
1998-04-05 23:04:50 +02:00
|
|
|
extern char *DatabasePath;
|
|
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/* now in utils/init/miscinit.c */
|
2015-01-13 13:12:37 +01:00
|
|
|
extern void InitPostmasterChild(void);
|
|
|
|
|
extern void InitStandaloneProcess(const char *argv0);
|
|
|
|
|
|
2000-01-13 19:26:18 +01:00
|
|
|
extern void SetDatabasePath(const char *path);
|
1998-09-01 06:40:42 +02:00
|
|
|
|
2015-05-09 19:06:49 +02:00
|
|
|
extern char *GetUserNameFromId(Oid roleid, bool noerr);
|
2005-10-15 04:49:52 +02:00
|
|
|
extern Oid GetUserId(void);
|
|
|
|
|
extern Oid GetOuterUserId(void);
|
|
|
|
|
extern Oid GetSessionUserId(void);
|
2014-10-23 14:18:45 +02:00
|
|
|
extern Oid GetAuthenticatedUserId(void);
|
Prevent indirect security attacks via changing session-local state within
an allegedly immutable index function. It was previously recognized that
we had to prevent such a function from executing SET/RESET ROLE/SESSION
AUTHORIZATION, or it could trivially obtain the privileges of the session
user. However, since there is in general no privilege checking for changes
of session-local state, it is also possible for such a function to change
settings in a way that might subvert later operations in the same session.
Examples include changing search_path to cause an unexpected function to
be called, or replacing an existing prepared statement with another one
that will execute a function of the attacker's choosing.
The present patch secures VACUUM, ANALYZE, and CREATE INDEX/REINDEX against
these threats, which are the same places previously deemed to need protection
against the SET ROLE issue. GUC changes are still allowed, since there are
many useful cases for that, but we prevent security problems by forcing a
rollback of any GUC change after completing the operation. Other cases are
handled by throwing an error if any change is attempted; these include temp
table creation, closing a cursor, and creating or deleting a prepared
statement. (In 7.4, the infrastructure to roll back GUC changes doesn't
exist, so we settle for rejecting changes of "search_path" in these contexts.)
Original report and patch by Gurjeet Singh, additional analysis by
Tom Lane.
Security: CVE-2009-4136
2009-12-09 22:57:51 +01:00
|
|
|
extern void GetUserIdAndSecContext(Oid *userid, int *sec_context);
|
|
|
|
|
extern void SetUserIdAndSecContext(Oid userid, int sec_context);
|
|
|
|
|
extern bool InLocalUserIdChange(void);
|
|
|
|
|
extern bool InSecurityRestrictedOperation(void);
|
2015-10-05 03:05:08 +02:00
|
|
|
extern bool InNoForceRLSOperation(void);
|
2008-01-03 22:23:15 +01:00
|
|
|
extern void GetUserIdAndContext(Oid *userid, bool *sec_def_context);
|
|
|
|
|
extern void SetUserIdAndContext(Oid userid, bool sec_def_context);
|
2015-02-02 22:23:59 +01:00
|
|
|
extern void InitializeSessionUserId(const char *rolename, Oid useroid);
|
2001-09-08 17:24:00 +02:00
|
|
|
extern void InitializeSessionUserIdStandalone(void);
|
2005-07-26 00:12:34 +02:00
|
|
|
extern void SetSessionAuthorization(Oid userid, bool is_superuser);
|
2005-10-15 04:49:52 +02:00
|
|
|
extern Oid GetCurrentRoleId(void);
|
2005-07-26 00:12:34 +02:00
|
|
|
extern void SetCurrentRoleId(Oid roleid, bool is_superuser);
|
2000-09-19 20:18:04 +02:00
|
|
|
|
2018-04-07 23:45:39 +02:00
|
|
|
extern void checkDataDir(void);
|
2000-11-04 13:43:24 +01:00
|
|
|
extern void SetDataDir(const char *dir);
|
2005-07-04 06:51:52 +02:00
|
|
|
extern void ChangeToDataDir(void);
|
2000-11-04 13:43:24 +01:00
|
|
|
|
2015-01-14 18:45:22 +01:00
|
|
|
extern void SwitchToSharedLatch(void);
|
|
|
|
|
extern void SwitchBackToLocalLatch(void);
|
|
|
|
|
|
2001-06-13 23:44:41 +02:00
|
|
|
/* in utils/misc/superuser.c */
|
|
|
|
|
extern bool superuser(void); /* current user is superuser */
|
2005-10-15 04:49:52 +02:00
|
|
|
extern bool superuser_arg(Oid roleid); /* given user is superuser */
|
2001-06-13 23:44:41 +02:00
|
|
|
|
|
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/*****************************************************************************
|
1997-09-07 07:04:48 +02:00
|
|
|
* pmod.h -- *
|
2014-05-06 18:12:18 +02:00
|
|
|
* POSTGRES processing mode definitions. *
|
1996-10-31 08:10:14 +01:00
|
|
|
*****************************************************************************/
|
2001-09-27 18:29:13 +02:00
|
|
|
|
1996-10-31 08:10:14 +01:00
|
|
|
/*
|
|
|
|
|
* Description:
|
2000-04-12 19:17:23 +02:00
|
|
|
* There are three processing modes in POSTGRES. They are
|
2001-01-14 06:08:17 +01:00
|
|
|
* BootstrapProcessing or "bootstrap," InitProcessing or
|
1996-10-31 08:10:14 +01:00
|
|
|
* "initialization," and NormalProcessing or "normal."
|
|
|
|
|
*
|
1999-10-06 23:58:18 +02:00
|
|
|
* The first two processing modes are used during special times. When the
|
1996-10-31 08:10:14 +01:00
|
|
|
* system state indicates bootstrap processing, transactions are all given
|
2001-01-14 06:08:17 +01:00
|
|
|
* transaction id "one" and are consequently guaranteed to commit. This mode
|
1996-10-31 08:10:14 +01:00
|
|
|
* is used during the initial generation of template databases.
|
|
|
|
|
*
|
2001-01-14 06:08:17 +01:00
|
|
|
* Initialization mode: used while starting a backend, until all normal
|
2014-05-06 18:12:18 +02:00
|
|
|
* initialization is complete. Some code behaves differently when executed
|
2001-01-14 06:08:17 +01:00
|
|
|
* in this mode to enable system bootstrapping.
|
1999-10-06 23:58:18 +02:00
|
|
|
*
|
Fix management of pendingOpsTable in auxiliary processes.
mdinit() was misusing IsBootstrapProcessingMode() to decide whether to
create an fsync pending-operations table in the current process. This led
to creating a table not only in the startup and checkpointer processes as
intended, but also in the bgwriter process, not to mention other auxiliary
processes such as walwriter and walreceiver. Creation of the table in the
bgwriter is fatal, because it absorbs fsync requests that should have gone
to the checkpointer; instead they just sit in bgwriter local memory and are
never acted on. So writes performed by the bgwriter were not being fsync'd
which could result in data loss after an OS crash. I think there is no
live bug with respect to walwriter and walreceiver because those never
perform any writes of shared buffers; but the potential is there for
future breakage in those processes too.
To fix, make AuxiliaryProcessMain() export the current process's
AuxProcType as a global variable, and then make mdinit() test directly for
the types of aux process that should have a pendingOpsTable. Having done
that, we might as well also get rid of the random bool flags such as
am_walreceiver that some of the aux processes had grown. (Note that we
could not have fixed the bug by examining those variables in mdinit(),
because it's called from BaseInit() which is run by AuxiliaryProcessMain()
before entering any of the process-type-specific code.)
Back-patch to 9.2, where the problem was introduced by the split-up of
bgwriter and checkpointer processes. The bogus pendingOpsTable exists
in walwriter and walreceiver processes in earlier branches, but absent
any evidence that it causes actual problems there, I'll leave the older
branches alone.
2012-07-18 21:28:10 +02:00
|
|
|
* If a POSTGRES backend process is in normal mode, then all code may be
|
|
|
|
|
* executed normally.
|
1996-10-31 08:10:14 +01:00
|
|
|
*/
|
|
|
|
|
|
1997-09-07 07:04:48 +02:00
|
|
|
typedef enum ProcessingMode
|
|
|
|
|
{
|
2001-10-28 07:26:15 +01:00
|
|
|
BootstrapProcessing, /* bootstrap creation of template database */
|
|
|
|
|
InitProcessing, /* initializing system */
|
|
|
|
|
NormalProcessing /* normal processing */
|
1997-09-08 23:56:23 +02:00
|
|
|
} ProcessingMode;
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2000-01-13 19:26:18 +01:00
|
|
|
extern ProcessingMode Mode;
|
|
|
|
|
|
2013-05-29 22:58:43 +02:00
|
|
|
#define IsBootstrapProcessingMode() (Mode == BootstrapProcessing)
|
Fix management of pendingOpsTable in auxiliary processes.
mdinit() was misusing IsBootstrapProcessingMode() to decide whether to
create an fsync pending-operations table in the current process. This led
to creating a table not only in the startup and checkpointer processes as
intended, but also in the bgwriter process, not to mention other auxiliary
processes such as walwriter and walreceiver. Creation of the table in the
bgwriter is fatal, because it absorbs fsync requests that should have gone
to the checkpointer; instead they just sit in bgwriter local memory and are
never acted on. So writes performed by the bgwriter were not being fsync'd
which could result in data loss after an OS crash. I think there is no
live bug with respect to walwriter and walreceiver because those never
perform any writes of shared buffers; but the potential is there for
future breakage in those processes too.
To fix, make AuxiliaryProcessMain() export the current process's
AuxProcType as a global variable, and then make mdinit() test directly for
the types of aux process that should have a pendingOpsTable. Having done
that, we might as well also get rid of the random bool flags such as
am_walreceiver that some of the aux processes had grown. (Note that we
could not have fixed the bug by examining those variables in mdinit(),
because it's called from BaseInit() which is run by AuxiliaryProcessMain()
before entering any of the process-type-specific code.)
Back-patch to 9.2, where the problem was introduced by the split-up of
bgwriter and checkpointer processes. The bogus pendingOpsTable exists
in walwriter and walreceiver processes in earlier branches, but absent
any evidence that it causes actual problems there, I'll leave the older
branches alone.
2012-07-18 21:28:10 +02:00
|
|
|
#define IsInitProcessingMode() (Mode == InitProcessing)
|
|
|
|
|
#define IsNormalProcessingMode() (Mode == NormalProcessing)
|
|
|
|
|
|
|
|
|
|
#define GetProcessingMode() Mode
|
2000-01-13 19:26:18 +01:00
|
|
|
|
|
|
|
|
#define SetProcessingMode(mode) \
|
2000-04-12 19:17:23 +02:00
|
|
|
do { \
|
2001-01-14 06:08:17 +01:00
|
|
|
AssertArg((mode) == BootstrapProcessing || \
|
|
|
|
|
(mode) == InitProcessing || \
|
|
|
|
|
(mode) == NormalProcessing); \
|
|
|
|
|
Mode = (mode); \
|
2000-04-12 19:17:23 +02:00
|
|
|
} while(0)
|
1996-10-31 08:10:14 +01:00
|
|
|
|
Fix management of pendingOpsTable in auxiliary processes.
mdinit() was misusing IsBootstrapProcessingMode() to decide whether to
create an fsync pending-operations table in the current process. This led
to creating a table not only in the startup and checkpointer processes as
intended, but also in the bgwriter process, not to mention other auxiliary
processes such as walwriter and walreceiver. Creation of the table in the
bgwriter is fatal, because it absorbs fsync requests that should have gone
to the checkpointer; instead they just sit in bgwriter local memory and are
never acted on. So writes performed by the bgwriter were not being fsync'd
which could result in data loss after an OS crash. I think there is no
live bug with respect to walwriter and walreceiver because those never
perform any writes of shared buffers; but the potential is there for
future breakage in those processes too.
To fix, make AuxiliaryProcessMain() export the current process's
AuxProcType as a global variable, and then make mdinit() test directly for
the types of aux process that should have a pendingOpsTable. Having done
that, we might as well also get rid of the random bool flags such as
am_walreceiver that some of the aux processes had grown. (Note that we
could not have fixed the bug by examining those variables in mdinit(),
because it's called from BaseInit() which is run by AuxiliaryProcessMain()
before entering any of the process-type-specific code.)
Back-patch to 9.2, where the problem was introduced by the split-up of
bgwriter and checkpointer processes. The bogus pendingOpsTable exists
in walwriter and walreceiver processes in earlier branches, but absent
any evidence that it causes actual problems there, I'll leave the older
branches alone.
2012-07-18 21:28:10 +02:00
|
|
|
|
|
|
|
|
/*
|
2014-05-06 18:12:18 +02:00
|
|
|
* Auxiliary-process type identifiers. These used to be in bootstrap.h
|
Fix management of pendingOpsTable in auxiliary processes.
mdinit() was misusing IsBootstrapProcessingMode() to decide whether to
create an fsync pending-operations table in the current process. This led
to creating a table not only in the startup and checkpointer processes as
intended, but also in the bgwriter process, not to mention other auxiliary
processes such as walwriter and walreceiver. Creation of the table in the
bgwriter is fatal, because it absorbs fsync requests that should have gone
to the checkpointer; instead they just sit in bgwriter local memory and are
never acted on. So writes performed by the bgwriter were not being fsync'd
which could result in data loss after an OS crash. I think there is no
live bug with respect to walwriter and walreceiver because those never
perform any writes of shared buffers; but the potential is there for
future breakage in those processes too.
To fix, make AuxiliaryProcessMain() export the current process's
AuxProcType as a global variable, and then make mdinit() test directly for
the types of aux process that should have a pendingOpsTable. Having done
that, we might as well also get rid of the random bool flags such as
am_walreceiver that some of the aux processes had grown. (Note that we
could not have fixed the bug by examining those variables in mdinit(),
because it's called from BaseInit() which is run by AuxiliaryProcessMain()
before entering any of the process-type-specific code.)
Back-patch to 9.2, where the problem was introduced by the split-up of
bgwriter and checkpointer processes. The bogus pendingOpsTable exists
in walwriter and walreceiver processes in earlier branches, but absent
any evidence that it causes actual problems there, I'll leave the older
branches alone.
2012-07-18 21:28:10 +02:00
|
|
|
* but it seems saner to have them here, with the ProcessingMode stuff.
|
|
|
|
|
* The MyAuxProcType global is defined and set in bootstrap.c.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
typedef enum
|
|
|
|
|
{
|
|
|
|
|
NotAnAuxProcess = -1,
|
|
|
|
|
CheckerProcess = 0,
|
|
|
|
|
BootstrapProcess,
|
|
|
|
|
StartupProcess,
|
|
|
|
|
BgWriterProcess,
|
|
|
|
|
CheckpointerProcess,
|
|
|
|
|
WalWriterProcess,
|
|
|
|
|
WalReceiverProcess,
|
|
|
|
|
|
|
|
|
|
NUM_AUXPROCTYPES /* Must be last! */
|
|
|
|
|
} AuxProcType;
|
|
|
|
|
|
|
|
|
|
extern AuxProcType MyAuxProcType;
|
|
|
|
|
|
|
|
|
|
#define AmBootstrapProcess() (MyAuxProcType == BootstrapProcess)
|
|
|
|
|
#define AmStartupProcess() (MyAuxProcType == StartupProcess)
|
2013-05-29 22:58:43 +02:00
|
|
|
#define AmBackgroundWriterProcess() (MyAuxProcType == BgWriterProcess)
|
Fix management of pendingOpsTable in auxiliary processes.
mdinit() was misusing IsBootstrapProcessingMode() to decide whether to
create an fsync pending-operations table in the current process. This led
to creating a table not only in the startup and checkpointer processes as
intended, but also in the bgwriter process, not to mention other auxiliary
processes such as walwriter and walreceiver. Creation of the table in the
bgwriter is fatal, because it absorbs fsync requests that should have gone
to the checkpointer; instead they just sit in bgwriter local memory and are
never acted on. So writes performed by the bgwriter were not being fsync'd
which could result in data loss after an OS crash. I think there is no
live bug with respect to walwriter and walreceiver because those never
perform any writes of shared buffers; but the potential is there for
future breakage in those processes too.
To fix, make AuxiliaryProcessMain() export the current process's
AuxProcType as a global variable, and then make mdinit() test directly for
the types of aux process that should have a pendingOpsTable. Having done
that, we might as well also get rid of the random bool flags such as
am_walreceiver that some of the aux processes had grown. (Note that we
could not have fixed the bug by examining those variables in mdinit(),
because it's called from BaseInit() which is run by AuxiliaryProcessMain()
before entering any of the process-type-specific code.)
Back-patch to 9.2, where the problem was introduced by the split-up of
bgwriter and checkpointer processes. The bogus pendingOpsTable exists
in walwriter and walreceiver processes in earlier branches, but absent
any evidence that it causes actual problems there, I'll leave the older
branches alone.
2012-07-18 21:28:10 +02:00
|
|
|
#define AmCheckpointerProcess() (MyAuxProcType == CheckpointerProcess)
|
|
|
|
|
#define AmWalWriterProcess() (MyAuxProcType == WalWriterProcess)
|
|
|
|
|
#define AmWalReceiverProcess() (MyAuxProcType == WalReceiverProcess)
|
1997-09-08 04:41:22 +02:00
|
|
|
|
2001-09-27 18:29:13 +02:00
|
|
|
|
|
|
|
|
/*****************************************************************************
|
|
|
|
|
* pinit.h -- *
|
2014-05-06 18:12:18 +02:00
|
|
|
* POSTGRES initialization and cleanup definitions. *
|
2001-09-27 18:29:13 +02:00
|
|
|
*****************************************************************************/
|
|
|
|
|
|
|
|
|
|
/* in utils/init/postinit.c */
|
2015-06-29 18:42:52 +02:00
|
|
|
extern void pg_split_opts(char **argv, int *argcp, const char *optstr);
|
2013-01-02 18:39:11 +01:00
|
|
|
extern void InitializeMaxBackends(void);
|
2009-09-01 02:09:42 +02:00
|
|
|
extern void InitPostgres(const char *in_dbname, Oid dboid, const char *username,
|
2018-04-05 18:59:32 +02:00
|
|
|
Oid useroid, char *out_dbname, bool override_allow_connections);
|
2001-09-27 18:29:13 +02:00
|
|
|
extern void BaseInit(void);
|
|
|
|
|
|
|
|
|
|
/* in utils/init/miscinit.c */
|
2006-01-05 11:07:46 +01:00
|
|
|
extern bool IgnoreSystemIndexes;
|
2009-01-03 21:03:08 +01:00
|
|
|
extern PGDLLIMPORT bool process_shared_preload_libraries_in_progress;
|
2013-06-13 04:28:24 +02:00
|
|
|
extern char *session_preload_libraries_string;
|
2006-08-15 20:26:59 +02:00
|
|
|
extern char *shared_preload_libraries_string;
|
|
|
|
|
extern char *local_preload_libraries_string;
|
2006-08-08 21:15:09 +02:00
|
|
|
|
2005-07-04 06:51:52 +02:00
|
|
|
extern void CreateDataDirLockFile(bool amPostmaster);
|
2012-08-10 23:26:44 +02:00
|
|
|
extern void CreateSocketLockFile(const char *socketfile, bool amPostmaster,
|
|
|
|
|
const char *socketDir);
|
|
|
|
|
extern void TouchSocketLockFiles(void);
|
2011-01-14 01:01:28 +01:00
|
|
|
extern void AddToDataDirLockFile(int target_line, const char *str);
|
Perform an immediate shutdown if the postmaster.pid file is removed.
The postmaster now checks every minute or so (worst case, at most two
minutes) that postmaster.pid is still there and still contains its own PID.
If not, it performs an immediate shutdown, as though it had received
SIGQUIT.
The original goal behind this change was to ensure that failed buildfarm
runs would get fully cleaned up, even if the test scripts had left a
postmaster running, which is not an infrequent occurrence. When the
buildfarm script removes a test postmaster's $PGDATA directory, its next
check on postmaster.pid will fail and cause it to exit. Previously, manual
intervention was often needed to get rid of such orphaned postmasters,
since they'd block new test postmasters from obtaining the expected socket
address.
However, by checking postmaster.pid and not something else, we can provide
additional robustness: manual removal of postmaster.pid is a frequent DBA
mistake, and now we can at least limit the damage that will ensue if a new
postmaster is started while the old one is still alive.
Back-patch to all supported branches, since we won't get the desired
improvement in buildfarm reliability otherwise.
2015-10-06 23:15:27 +02:00
|
|
|
extern bool RecheckDataDirLockFile(void);
|
2000-07-02 17:21:27 +02:00
|
|
|
extern void ValidatePgVersion(const char *path);
|
2006-08-15 20:26:59 +02:00
|
|
|
extern void process_shared_preload_libraries(void);
|
2013-06-13 04:28:24 +02:00
|
|
|
extern void process_session_preload_libraries(void);
|
2008-12-11 08:34:09 +01:00
|
|
|
extern void pg_bindtextdomain(const char *domain);
|
2013-04-01 19:09:24 +02:00
|
|
|
extern bool has_rolreplication(Oid roleid);
|
2000-07-02 17:21:27 +02:00
|
|
|
|
2008-04-23 15:44:59 +02:00
|
|
|
/* in access/transam/xlog.c */
|
|
|
|
|
extern bool BackupInProgress(void);
|
|
|
|
|
extern void CancelBackup(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 /* MISCADMIN_H */
|
