2011-11-02 15:25:01 +01:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* startup.h
|
|
|
|
* Exports from postmaster/startup.c.
|
|
|
|
*
|
2024-01-04 02:49:05 +01:00
|
|
|
* Portions Copyright (c) 1996-2024, PostgreSQL Global Development Group
|
2011-11-02 15:25:01 +01:00
|
|
|
*
|
|
|
|
* src/include/postmaster/startup.h
|
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
#ifndef _STARTUP_H
|
|
|
|
#define _STARTUP_H
|
|
|
|
|
Report progress of startup operations that take a long time.
Users sometimes get concerned whe they start the server and it
emits a few messages and then doesn't emit any more messages for
a long time. Generally, what's happening is either that the
system is taking a long time to apply WAL, or it's taking a
long time to reset unlogged relations, or it's taking a long
time to fsync the data directory, but it's not easy to tell
which is the case.
To fix that, add a new 'log_startup_progress_interval' setting,
by default 10s. When an operation that is known to be potentially
long-running takes more than this amount of time, we'll log a
status update each time this interval elapses.
To avoid undesirable log chatter, don't log anything about WAL
replay when in standby mode.
Nitin Jadhav and Robert Haas, reviewed by Amul Sul, Bharath
Rupireddy, Justin Pryzby, Michael Paquier, and Álvaro Herrera.
Discussion: https://postgr.es/m/CA+TgmoaHQrgDFOBwgY16XCoMtXxsrVGFB2jNCvb7-ubuEe1MGg@mail.gmail.com
Discussion: https://postgr.es/m/CAMm1aWaHF7VE69572_OLQ+MgpT5RUiUDgF1x5RrtkJBLdpRj3Q@mail.gmail.com
2021-10-25 17:51:57 +02:00
|
|
|
/*
|
|
|
|
* Log the startup progress message if a timer has expired.
|
|
|
|
*/
|
|
|
|
#define ereport_startup_progress(msg, ...) \
|
|
|
|
do { \
|
|
|
|
long secs; \
|
|
|
|
int usecs; \
|
|
|
|
if (has_startup_progress_timeout_expired(&secs, &usecs)) \
|
|
|
|
ereport(LOG, errmsg(msg, secs, (usecs / 10000), __VA_ARGS__ )); \
|
|
|
|
} while(0)
|
|
|
|
|
2022-04-08 14:16:38 +02:00
|
|
|
extern PGDLLIMPORT int log_startup_progress_interval;
|
Report progress of startup operations that take a long time.
Users sometimes get concerned whe they start the server and it
emits a few messages and then doesn't emit any more messages for
a long time. Generally, what's happening is either that the
system is taking a long time to apply WAL, or it's taking a
long time to reset unlogged relations, or it's taking a long
time to fsync the data directory, but it's not easy to tell
which is the case.
To fix that, add a new 'log_startup_progress_interval' setting,
by default 10s. When an operation that is known to be potentially
long-running takes more than this amount of time, we'll log a
status update each time this interval elapses.
To avoid undesirable log chatter, don't log anything about WAL
replay when in standby mode.
Nitin Jadhav and Robert Haas, reviewed by Amul Sul, Bharath
Rupireddy, Justin Pryzby, Michael Paquier, and Álvaro Herrera.
Discussion: https://postgr.es/m/CA+TgmoaHQrgDFOBwgY16XCoMtXxsrVGFB2jNCvb7-ubuEe1MGg@mail.gmail.com
Discussion: https://postgr.es/m/CAMm1aWaHF7VE69572_OLQ+MgpT5RUiUDgF1x5RrtkJBLdpRj3Q@mail.gmail.com
2021-10-25 17:51:57 +02:00
|
|
|
|
2011-11-02 15:25:01 +01:00
|
|
|
extern void HandleStartupProcInterrupts(void);
|
2024-03-18 10:35:08 +01:00
|
|
|
extern void StartupProcessMain(char *startup_data, size_t startup_data_len) pg_attribute_noreturn();
|
2011-11-02 15:25:01 +01:00
|
|
|
extern void PreRestoreCommand(void);
|
|
|
|
extern void PostRestoreCommand(void);
|
2020-03-24 04:46:48 +01:00
|
|
|
extern bool IsPromoteSignaled(void);
|
|
|
|
extern void ResetPromoteSignaled(void);
|
2011-11-02 15:25:01 +01:00
|
|
|
|
2023-02-06 16:51:08 +01:00
|
|
|
extern void enable_startup_progress_timeout(void);
|
|
|
|
extern void disable_startup_progress_timeout(void);
|
Report progress of startup operations that take a long time.
Users sometimes get concerned whe they start the server and it
emits a few messages and then doesn't emit any more messages for
a long time. Generally, what's happening is either that the
system is taking a long time to apply WAL, or it's taking a
long time to reset unlogged relations, or it's taking a long
time to fsync the data directory, but it's not easy to tell
which is the case.
To fix that, add a new 'log_startup_progress_interval' setting,
by default 10s. When an operation that is known to be potentially
long-running takes more than this amount of time, we'll log a
status update each time this interval elapses.
To avoid undesirable log chatter, don't log anything about WAL
replay when in standby mode.
Nitin Jadhav and Robert Haas, reviewed by Amul Sul, Bharath
Rupireddy, Justin Pryzby, Michael Paquier, and Álvaro Herrera.
Discussion: https://postgr.es/m/CA+TgmoaHQrgDFOBwgY16XCoMtXxsrVGFB2jNCvb7-ubuEe1MGg@mail.gmail.com
Discussion: https://postgr.es/m/CAMm1aWaHF7VE69572_OLQ+MgpT5RUiUDgF1x5RrtkJBLdpRj3Q@mail.gmail.com
2021-10-25 17:51:57 +02:00
|
|
|
extern void begin_startup_progress_phase(void);
|
|
|
|
extern void startup_progress_timeout_handler(void);
|
|
|
|
extern bool has_startup_progress_timeout_expired(long *secs, int *usecs);
|
|
|
|
|
2011-11-02 15:25:01 +01:00
|
|
|
#endif /* _STARTUP_H */
|