open-dsi
/
postgres
mirror of https://github.com/postgres/postgres
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
17707 Commits
38 Branches
669 Tags
770 MiB
Tag: Branch: Tree: d531fd2cdc
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'd531fd2cdc'
${ noResults }
postgres/src/include/storage/pmsignal.h

40 lines
1.3 KiB
Raw Normal View History Unescape

Merge three existing ways of signaling postmaster from child processes, so that only one signal number is used not three. Flags in shared memory tell the reason(s) for the current signal. This method is extensible to handle more signal reasons without chewing up even more signal numbers, but the immediate reason is to keep pg_pwd reloads separate from SIGHUP processing in the postmaster. Also clean up some problems in the postmaster with delayed response to checkpoint status changes --- basically, it wouldn't schedule a checkpoint if it wasn't getting connection requests on a regular basis.
24 years ago
/*-------------------------------------------------------------------------
*
* pmsignal.h
* routines for signaling the postmaster from its child processes
*
*
Update copyrights to 2003.
23 years ago
* Portions Copyright (c) 1996-2003, PostgreSQL Global Development Group
Merge three existing ways of signaling postmaster from child processes, so that only one signal number is used not three. Flags in shared memory tell the reason(s) for the current signal. This method is extensible to handle more signal reasons without chewing up even more signal numbers, but the immediate reason is to keep pg_pwd reloads separate from SIGHUP processing in the postmaster. Also clean up some problems in the postmaster with delayed response to checkpoint status changes --- basically, it wouldn't schedule a checkpoint if it wasn't getting connection requests on a regular basis.
24 years ago
* Portions Copyright (c) 1994, Regents of the University of California
*
Handle impending sinval queue overflow by means of a separate signal (SIGUSR1, which we have not been using recently) instead of piggybacking on SIGUSR2-driven NOTIFY processing. This has several good results: the processing needed to drain the sinval queue is a lot less than the processing needed to answer a NOTIFY; there's less contention since we don't have a bunch of backends all trying to acquire exclusive lock on pg_listener; backends that are sitting inside a transaction block can still drain the queue, whereas NOTIFY processing can't run if there's an open transaction block. (This last is a fairly serious issue that I don't think we ever recognized before --- with clients like JDBC that tend to sit with open transaction blocks, the sinval queue draining mechanism never really worked as intended, probably resulting in a lot of useless cache-reset overhead.) This is the last of several proposed changes in response to Philip Warner's recent report of sinval-induced performance problems.
22 years ago
* $PostgreSQL: pgsql/src/include/storage/pmsignal.h,v 1.7 2004/05/23 03:50:45 tgl Exp $
Merge three existing ways of signaling postmaster from child processes, so that only one signal number is used not three. Flags in shared memory tell the reason(s) for the current signal. This method is extensible to handle more signal reasons without chewing up even more signal numbers, but the immediate reason is to keep pg_pwd reloads separate from SIGHUP processing in the postmaster. Also clean up some problems in the postmaster with delayed response to checkpoint status changes --- basically, it wouldn't schedule a checkpoint if it wasn't getting connection requests on a regular basis.
24 years ago
*
*-------------------------------------------------------------------------
*/
#ifndef PMSIGNAL_H
#define PMSIGNAL_H
/*
* Reasons for signaling the postmaster. We can cope with simultaneous
* signals for different reasons. If the same reason is signaled multiple
* times in quick succession, however, the postmaster is likely to observe
* only one notification of it. This is okay for the present uses.
*/
typedef enum
{
PMSIGNAL_DO_CHECKPOINT, /* request to start a checkpoint */
PMSIGNAL_PASSWORD_CHANGE, /* pg_pwd file has changed */
Handle impending sinval queue overflow by means of a separate signal (SIGUSR1, which we have not been using recently) instead of piggybacking on SIGUSR2-driven NOTIFY processing. This has several good results: the processing needed to drain the sinval queue is a lot less than the processing needed to answer a NOTIFY; there's less contention since we don't have a bunch of backends all trying to acquire exclusive lock on pg_listener; backends that are sitting inside a transaction block can still drain the queue, whereas NOTIFY processing can't run if there's an open transaction block. (This last is a fairly serious issue that I don't think we ever recognized before --- with clients like JDBC that tend to sit with open transaction blocks, the sinval queue draining mechanism never really worked as intended, probably resulting in a lot of useless cache-reset overhead.) This is the last of several proposed changes in response to Philip Warner's recent report of sinval-induced performance problems.
22 years ago
PMSIGNAL_WAKEN_CHILDREN, /* send a SIGUSR1 signal to all backends */
Merge three existing ways of signaling postmaster from child processes, so that only one signal number is used not three. Flags in shared memory tell the reason(s) for the current signal. This method is extensible to handle more signal reasons without chewing up even more signal numbers, but the immediate reason is to keep pg_pwd reloads separate from SIGHUP processing in the postmaster. Also clean up some problems in the postmaster with delayed response to checkpoint status changes --- basically, it wouldn't schedule a checkpoint if it wasn't getting connection requests on a regular basis.
24 years ago
NUM_PMSIGNALS /* Must be last value of enum! */
pgindent run.
24 years ago
} PMSignalReason;
Merge three existing ways of signaling postmaster from child processes, so that only one signal number is used not three. Flags in shared memory tell the reason(s) for the current signal. This method is extensible to handle more signal reasons without chewing up even more signal numbers, but the immediate reason is to keep pg_pwd reloads separate from SIGHUP processing in the postmaster. Also clean up some problems in the postmaster with delayed response to checkpoint status changes --- basically, it wouldn't schedule a checkpoint if it wasn't getting connection requests on a regular basis.
24 years ago
/*
* prototypes for functions in pmsignal.c
*/
extern void PMSignalInit(void);
extern void SendPostmasterSignal(PMSignalReason reason);
extern bool CheckPostmasterSignal(PMSignalReason reason);
New pgindent run with fixes suggested by Tom. Patch manually reviewed, initdb/regression tests pass.
24 years ago
#endif /* PMSIGNAL_H */