Tom Lane ebfc56d3fb 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.		2004-05-23 03:50:45 +00:00
..
buffer	Get rid of rd_nblocks field in relcache entries. Turns out this was	2004-05-08 19:09:25 +00:00
file	Replace opendir/closedir calls throughout the backend with AllocateDir	2004-02-23 23:03:10 +00:00
freespace	Ensure that close() and fclose() are checked for errors, at least in	2004-01-26 22:35:32 +00:00
ipc	Handle impending sinval queue overflow by means of a separate signal	2004-05-23 03:50:45 +00:00
large_object	$Header: -> $PostgreSQL Changes ...	2003-11-29 19:52:15 +00:00
lmgr	When changing select() calls for delays into pg_usleep(), two comments	2004-03-23 21:39:46 +00:00
page	$Header: -> $PostgreSQL Changes ...	2003-11-29 19:52:15 +00:00
smgr	* Most changes are to fix warnings issued when compiling win32	2004-04-19 17:42:59 +00:00
Makefile	$Header: -> $PostgreSQL Changes ...	2003-11-29 19:52:15 +00:00