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
|
|
|
*
|
2015-01-06 17:43:47 +01:00
|
|
|
* Portions Copyright (c) 1996-2015, 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
|
|
|
|
|
|
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
|
|
|
|
2008-02-20 23:46:24 +01:00
|
|
|
#define PG_BACKEND_VERSIONSTR "postgres (PostgreSQL) " PG_VERSION "\n"
|
2004-05-30 00:48:23 +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: */
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT volatile bool InterruptPending;
|
2014-02-17 02:12:43 +01:00
|
|
|
extern PGDLLIMPORT volatile bool QueryCancelPending;
|
|
|
|
|
extern PGDLLIMPORT volatile bool ProcDiePending;
|
2001-03-22 05:01:46 +01:00
|
|
|
|
2011-12-09 10:37:21 +01:00
|
|
|
extern volatile bool ClientConnectionLost;
|
|
|
|
|
|
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)
|
2004-08-29 07:07:03 +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
|
|
|
|
|
*/
|
2004-01-26 23:59:54 +01:00
|
|
|
extern pid_t PostmasterPid;
|
2003-05-28 20:19:09 +02:00
|
|
|
extern bool IsPostmasterEnvironment;
|
2009-01-05 03:27:45 +01:00
|
|
|
extern PGDLLIMPORT bool IsUnderPostmaster;
|
Background worker processes
Background workers are postmaster subprocesses that run arbitrary
user-specified code. They can request shared memory access as well as
backend database connections; or they can just use plain libpq frontend
database connections.
Modules listed in shared_preload_libraries can register background
workers in their _PG_init() function; this is early enough that it's not
necessary to provide an extra GUC option, because the necessary extra
resources can be allocated early on. Modules can install more than one
bgworker, if necessary.
Care is taken that these extra processes do not interfere with other
postmaster tasks: only one such process is started on each ServerLoop
iteration. This means a large number of them could be waiting to be
started up and postmaster is still able to quickly service external
connection requests. Also, shutdown sequence should not be impacted by
a worker process that's reasonably well behaved (i.e. promptly responds
to termination signals.)
The current implementation lets worker processes specify their start
time, i.e. at what point in the server startup process they are to be
started: right after postmaster start (in which case they mustn't ask
for shared memory access), when consistent state has been reached
(useful during recovery in a HOT standby server), or when recovery has
terminated (i.e. when normal backends are allowed).
In case of a bgworker crash, actions to take depend on registration
data: if shared memory was requested, then all other connections are
taken down (as well as other bgworkers), just like it were a regular
backend crashing. The bgworker itself is restarted, too, within a
configurable timeframe (which can be configured to be never).
More features to add to this framework can be imagined without much
effort, and have been discussed, but this seems good enough as a useful
unit already.
An elementary sample module is supplied.
Author: Álvaro Herrera
This patch is loosely based on prior patches submitted by KaiGai Kohei,
and unsubmitted code by Simon Riggs.
Reviewed by: KaiGai Kohei, Markus Wanner, Andres Freund,
Heikki Linnakangas, Simon Riggs, Amit Kapila
2012-12-06 18:57:52 +01:00
|
|
|
extern bool IsBackgroundWorker;
|
2014-08-26 15:25:18 +02:00
|
|
|
extern PGDLLIMPORT bool IsBinaryUpgrade;
|
2003-05-28 20:19:09 +02:00
|
|
|
|
|
|
|
|
extern bool ExitOnAnyError;
|
|
|
|
|
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT char *DataDir;
|
1996-10-31 08:10:14 +01:00
|
|
|
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT int NBuffers;
|
2004-05-30 00:48:23 +02:00
|
|
|
extern int MaxBackends;
|
2007-04-16 20:30:04 +02:00
|
|
|
extern int MaxConnections;
|
Add new GUC, max_worker_processes, limiting number of bgworkers.
In 9.3, there's no particular limit on the number of bgworkers;
instead, we just count up the number that are actually registered,
and use that to set MaxBackends. However, that approach causes
problems for Hot Standby, which needs both MaxBackends and the
size of the lock table to be the same on the standby as on the
master, yet it may not be desirable to run the same bgworkers in
both places. 9.3 handles that by failing to notice the problem,
which will probably work fine in nearly all cases anyway, but is
not theoretically sound.
A further problem with simply counting the number of registered
workers is that new workers can't be registered without a
postmaster restart. This is inconvenient for administrators,
since bouncing the postmaster causes an interruption of service.
Moreover, there are a number of applications for background
processes where, by necessity, the background process must be
started on the fly (e.g. parallel query). While this patch
doesn't actually make it possible to register new background
workers after startup time, it's a necessary prerequisite.
Patch by me. Review by Michael Paquier.
2013-07-04 17:24:24 +02:00
|
|
|
extern int max_worker_processes;
|
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;
|
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;
|
1998-09-01 06:40:42 +02:00
|
|
|
extern long 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;
|
1999-05-25 18:15:34 +02:00
|
|
|
extern bool allowSystemTableMods;
|
2007-07-25 14:22:54 +02:00
|
|
|
extern PGDLLIMPORT int work_mem;
|
|
|
|
|
extern PGDLLIMPORT int maintenance_work_mem;
|
2004-02-06 20:36:18 +01:00
|
|
|
|
|
|
|
|
extern int VacuumCostPageHit;
|
|
|
|
|
extern int VacuumCostPageMiss;
|
|
|
|
|
extern int VacuumCostPageDirty;
|
|
|
|
|
extern int VacuumCostLimit;
|
2004-08-06 06:15:09 +02:00
|
|
|
extern int 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
|
|
|
|
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
|
|
|
|
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
|
|
|
|
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,
|
2015-02-02 22:23:59 +01:00
|
|
|
Oid useroid, char *out_dbname);
|
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
|
|
|
|
2011-01-14 01:01:28 +01:00
|
|
|
/*
|
|
|
|
|
* As of 9.1, the contents of the data-directory lock file are:
|
|
|
|
|
*
|
|
|
|
|
* line #
|
|
|
|
|
* 1 postmaster PID (or negative of a standalone backend's PID)
|
|
|
|
|
* 2 data directory path
|
|
|
|
|
* 3 postmaster start timestamp (time_t representation)
|
|
|
|
|
* 4 port number
|
2012-08-10 23:26:44 +02:00
|
|
|
* 5 first Unix socket directory path (empty if none)
|
2011-01-14 01:01:28 +01:00
|
|
|
* 6 first listen_address (IP address or "*"; empty if no TCP port)
|
|
|
|
|
* 7 shared memory key (not present on Windows)
|
|
|
|
|
*
|
|
|
|
|
* Lines 6 and up are added via AddToDataDirLockFile() after initial file
|
2012-10-15 10:02:02 +02:00
|
|
|
* creation.
|
2011-01-14 01:01:28 +01:00
|
|
|
*
|
|
|
|
|
* The socket lock file, if used, has the same contents as lines 1-5.
|
|
|
|
|
*/
|
|
|
|
|
#define LOCK_FILE_LINE_PID 1
|
|
|
|
|
#define LOCK_FILE_LINE_DATA_DIR 2
|
|
|
|
|
#define LOCK_FILE_LINE_START_TIME 3
|
|
|
|
|
#define LOCK_FILE_LINE_PORT 4
|
|
|
|
|
#define LOCK_FILE_LINE_SOCKET_DIR 5
|
|
|
|
|
#define LOCK_FILE_LINE_LISTEN_ADDR 6
|
|
|
|
|
#define LOCK_FILE_LINE_SHMEM_KEY 7
|
|
|
|
|
|
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);
|
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);
|
|
|
|
|
|
2001-11-05 18:46:40 +01:00
|
|
|
#endif /* MISCADMIN_H */
|
