mirror of
https://git.postgresql.org/git/postgresql.git
synced 2024-08-27 09:27:20 +02:00
ebfc56d3fb
(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. |
||
|---|---|---|
| .. | ||
| ipc.c | ||
| ipci.c | ||
| Makefile | ||
| pmsignal.c | ||
| README | ||
| shmem.c | ||
| shmqueue.c | ||
| sinval.c | ||
| sinvaladt.c | ||
$PostgreSQL: pgsql/src/backend/storage/ipc/README,v 1.4 2003/11/29 19:51:56 pgsql Exp $ Mon Jul 18 11:09:22 PDT 1988 W.KLAS Cache invalidation synchronization routines: =========================================== The cache synchronization is done using a message queue. Every backend can register a message which then has to be read by all backends. A message read by all backends is removed from the queue automatically. If a message has been lost because the buffer was full, all backends that haven't read this message will be told that they have to reset their cache state. This is done at the time when they try to read the message queue. The message queue is implemented as a shared buffer segment. Actually, the queue is a circle to allow fast inserting, reading (invalidate data) and maintaining the buffer.