rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
postgresql/src/backend/postmaster/pgstat.c

5527 lines
145 KiB
C
Raw Normal View History

The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
* pgstat.c
*
* All the statistics collector stuff hacked up in one big, ugly file.
*
* TODO: - Separate collector, postmaster and backend stuff
* into different files.
*
* - Add some automatic call for pgstat vacuuming.
*
* - Add a pgstat config column to pg_database, so this
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
* entire thing can be enabled/disabled on a per db basis.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*
Update copyright for 2016 Backpatch certain files through 9.1
2016-01-02 19:33:40 +01:00
* Copyright (c) 2001-2016, PostgreSQL Global Development Group
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*
Remove cvs keywords from all files.
2010-09-20 22:08:53 +02:00
* src/backend/postmaster/pgstat.c
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
portability enhancements
2001-06-30 21:01:27 +02:00
#include "postgres.h"
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
#include <unistd.h>
#include <fcntl.h>
#include <sys/param.h>
#include <sys/time.h>
#include <sys/socket.h>
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
#include <netdb.h>
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
#include <netinet/in.h>
#include <arpa/inet.h>
#include <signal.h>
Adjust our timezone library to use pg_time_t (typedef'd as int64) in place of time_t, as per prior discussion. The behavior does not change on machines without a 64-bit-int type, but on machines with one, which is most, we are rid of the bizarre boundary behavior at the edges of the 32-bit-time_t range (1901 and 2038). The system will now treat times over the full supported timestamp range as being in your local time zone. It may seem a little bizarre to consider that times in 4000 BC are PST or EST, but this is surely at least as reasonable as propagating Gregorian calendar rules back that far. I did not modify the format of the zic timezone database files, which means that for the moment the system will not know about daylight-savings periods outside the range 1901-2038. Given the way the files are set up, it's not a simple decision like 'widen to 64 bits'; we have to actually think about the range of years that need to be supported. We should probably inquire what the plans of the upstream zic people are before making any decisions of our own.
2004-06-03 04:08:07 +02:00
#include <time.h>
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
#include "pgstat.h"
Fix handling of SIGCHLD, per recent pghackers discussion: on some platforms system(2) gets confused unless the signal handler is set to SIG_DFL, not SIG_IGN. pgstats.c now uses pqsignal() as it should, not signal(). Also, arrange for the stats collector process to show a reasonable ID in 'ps', rather than looking like a postmaster.
2001-08-04 02:14:43 +02:00
#include "access/heapam.h"
Split tuple struct defs from htup.h to htup_details.h This reduces unnecessary exposure of other headers through htup.h, which is very widely included by many files. I have chosen to move the function prototypes to the new file as well, because that means htup.h no longer needs to include tupdesc.h. In itself this doesn't have much effect in indirect inclusion of tupdesc.h throughout the tree, because it's also required by execnodes.h; but it's something to explore in the future, and it seemed best to do the htup.h change now while I'm busy with it.
2012-08-30 22:15:44 +02:00
#include "access/htup_details.h"
Allow include files to compile own their own. Strip unused include files out unused include files, and add needed includes to C files. The next step is to remove unused include files in C files.
2006-07-13 18:49:20 +02:00
#include "access/transam.h"
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
#include "access/twophase_rmgr.h"
Separate out bgwriter code into a logically separate module, rather than being random pieces of other files. Give bgwriter responsibility for all checkpoint activity (other than a post-recovery checkpoint); so this child process absorbs the functionality of the former transient checkpoint and shutdown subprocesses. While at it, create an actual include file for postmaster.c, which for some reason never had its own file before.
2004-05-30 00:48:23 +02:00
#include "access/xact.h"
Fix handling of SIGCHLD, per recent pghackers discussion: on some platforms system(2) gets confused unless the signal handler is set to SIG_DFL, not SIG_IGN. pgstats.c now uses pqsignal() as it should, not signal(). Also, arrange for the stats collector process to show a reasonable ID in 'ps', rather than looking like a postmaster.
2001-08-04 02:14:43 +02:00
#include "catalog/pg_database.h"
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
#include "catalog/pg_proc.h"
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
#include "lib/ilist.h"
Allow include files to compile own their own. Strip unused include files out unused include files, and add needed includes to C files. The next step is to remove unused include files in C files.
2006-07-13 18:49:20 +02:00
#include "libpq/ip.h"
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
#include "libpq/libpq.h"
Separate out bgwriter code into a logically separate module, rather than being random pieces of other files. Give bgwriter responsibility for all checkpoint activity (other than a post-recovery checkpoint); so this child process absorbs the functionality of the former transient checkpoint and shutdown subprocesses. While at it, create an actual include file for postmaster.c, which for some reason never had its own file before.
2004-05-30 00:48:23 +02:00
#include "libpq/pqsignal.h"
pgstat's truncation of query string needs to be multibyte-aware. Patch from sugita@sra.co.jp.
2002-02-07 23:20:26 +01:00
#include "mb/pg_wchar.h"
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
#include "miscadmin.h"
Add a few more DTrace probes to the backend. Robert Lor
2008-08-01 15:16:09 +02:00
#include "pg_trace.h"
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
#include "postmaster/autovacuum.h"
Use fork_process() to avoid some fork()-related boilerplate code when forking the stats collector child process.
2005-04-08 02:55:07 +02:00
#include "postmaster/fork_process.h"
Separate out bgwriter code into a logically separate module, rather than being random pieces of other files. Give bgwriter responsibility for all checkpoint activity (other than a post-recovery checkpoint); so this child process absorbs the functionality of the former transient checkpoint and shutdown subprocesses. While at it, create an actual include file for postmaster.c, which for some reason never had its own file before.
2004-05-30 00:48:23 +02:00
#include "postmaster/postmaster.h"
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
#include "storage/backendid.h"
Make it easy to detach completely from shared memory. The new function dsm_detach_all() can be used either by postmaster children that don't wish to take any risk of accidentally corrupting shared memory; or by forked children of regular backends with the same need. This patch also updates the postmaster children that already do PGSharedMemoryDetach() to do dsm_detach_all() as well. Per discussion with Tom Lane.
2014-03-18 12:58:53 +01:00
#include "storage/dsm.h"
Use AllocateFile(), FreeFile() and palloc() rather than fopen(), fclose() and malloc() in pgstat.c, respectively. This simplifies error recovery, as well as being more consistent with the rest of the backend.
2004-10-28 03:38:41 +02:00
#include "storage/fd.h"
Create an internal semaphore API that is not tied to SysV semaphores. As proof of concept, provide an alternate implementation based on POSIX semaphores. Also push the SysV shared-memory implementation into a separate file so that it can be replaced conveniently.
2002-05-05 02:03:29 +02:00
#include "storage/ipc.h"
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
#include "storage/latch.h"
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
#include "storage/lmgr.h"
Cause stats processes to detach from shared memory when started, so that they do not prevent the postmaster from deleting the shmem segment during a post-backend-crash restart cycle. Per recent discussion.
2003-11-07 22:55:50 +01:00
#include "storage/pg_shmem.h"
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
#include "storage/procsignal.h"
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
#include "storage/sinvaladt.h"
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
#include "utils/ascii.h"
Simplify and rename some GUC variables, per various recent discussions: * stats_start_collector goes away; we always start the collector process, unless prevented by a problem with setting up the stats UDP socket. * stats_reset_on_server_start goes away; it seems useless in view of the availability of pg_stat_reset(). * stats_block_level and stats_row_level are merged into a single variable "track_counts", which controls all reports sent to the collector process. * stats_command_string is renamed to track_activities. * log_autovacuum is renamed to log_autovacuum_min_duration to better reflect its meaning. The log_autovacuum change is not a compatibility issue since it didn't exist before 8.3 anyway. The other changes need to be release-noted.
2007-09-24 05:12:23 +02:00
#include "utils/guc.h"
Separate out bgwriter code into a logically separate module, rather than being random pieces of other files. Give bgwriter responsibility for all checkpoint activity (other than a post-recovery checkpoint); so this child process absorbs the functionality of the former transient checkpoint and shutdown subprocesses. While at it, create an actual include file for postmaster.c, which for some reason never had its own file before.
2004-05-30 00:48:23 +02:00
#include "utils/memutils.h"
Fix handling of SIGCHLD, per recent pghackers discussion: on some platforms system(2) gets confused unless the signal handler is set to SIG_DFL, not SIG_IGN. pgstats.c now uses pqsignal() as it should, not signal(). Also, arrange for the stats collector process to show a reasonable ID in 'ps', rather than looking like a postmaster.
2001-08-04 02:14:43 +02:00
#include "utils/ps_status.h"
Improve our #include situation by moving pointer types away from the corresponding struct definitions. This allows other headers to avoid including certain highly-loaded headers such as rel.h and relscan.h, instead using just relcache.h, heapam.h or genam.h, which are more lightweight and thus cause less unnecessary dependencies.
2008-06-19 02:46:06 +02:00
#include "utils/rel.h"
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans. SnapshotNow scans have the undesirable property that, in the face of concurrent updates, the scan can fail to see either the old or the new versions of the row. In many cases, we work around this by requiring DDL operations to hold AccessExclusiveLock on the object being modified; in some cases, the existing locking is inadequate and random failures occur as a result. This commit doesn't change anything related to locking, but will hopefully pave the way to allowing lock strength reductions in the future. The major issue has held us back from making this change in the past is that taking an MVCC snapshot is significantly more expensive than using a static special snapshot such as SnapshotNow. However, testing of various worst-case scenarios reveals that this problem is not severe except under fairly extreme workloads. To mitigate those problems, we avoid retaking the MVCC snapshot for each new scan; instead, we take a new snapshot only when invalidation messages have been processed. The catcache machinery already requires that invalidation messages be sent before releasing the related heavyweight lock; else other backends might rely on locally-cached data rather than scanning the catalog at all. Thus, making snapshot reuse dependent on the same guarantees shouldn't break anything that wasn't already subtly broken. Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
#include "utils/snapmgr.h"
Move Timestamp/Interval typedefs and basic macros into datatype/timestamp.h. As per my recent proposal, this refactors things so that these typedefs and macros are available in a header that can be included in frontend-ish code. I also changed various headers that were undesirably including utils/timestamp.h to include datatype/timestamp.h instead. Unsurprisingly, this showed that half the system was getting utils/timestamp.h by way of xlog.h. No actual code changes here, just header refactoring.
2011-09-09 19:23:41 +02:00
#include "utils/timestamp.h"
Move the HTSU_Result enum definition into snapshot.h, to avoid including tqual.h into heapam.h. This makes all inclusion of tqual.h explicit. I also sorted alphabetically the includes on some source files.
2008-03-26 22:10:39 +01:00
#include "utils/tqual.h"
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Adjust pgstat message definitions so that the target message size is specified in just one place and adhered to exactly, rather than just more or less. A side effect is to increase PGSTAT_ACTIVITY_SIZE (maximum reported query length) from 256 to nearly 1000.
2004-06-26 18:32:04 +02:00
/* ----------
* Timer definitions.
* ----------
*/
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
#define PGSTAT_STAT_INTERVAL 500 /* Minimum time between stats file
* updates; in milliseconds. */
Remove debug logging for pgstat wait timeout. This reverts commit 79b2ee20c8a041a85dd230c4e787bef22edae57b, which proved to not be very informative; it looks like the "pgstat wait timeout" warnings in the buildfarm are just a symptom of running on heavily loaded machines, and there isn't any weird mechanism causing them to appear. To try to reduce the frequency of buildfarm failures from this effect, increase PGSTAT_MAX_WAIT_TIME from 5 seconds to 10. Also, arrange to not send a fresh inquiry message every single time through the loop, as that seems more likely to cause problems (by swamping the collector) than fix them. We'll now send an inquiry the first time through the delay loop, and every 640 msec thereafter.
2011-09-17 00:25:27 +02:00
#define PGSTAT_RETRY_DELAY 10 /* How long to wait between checks for
* a new file; in milliseconds. */
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
Remove debug logging for pgstat wait timeout. This reverts commit 79b2ee20c8a041a85dd230c4e787bef22edae57b, which proved to not be very informative; it looks like the "pgstat wait timeout" warnings in the buildfarm are just a symptom of running on heavily loaded machines, and there isn't any weird mechanism causing them to appear. To try to reduce the frequency of buildfarm failures from this effect, increase PGSTAT_MAX_WAIT_TIME from 5 seconds to 10. Also, arrange to not send a fresh inquiry message every single time through the loop, as that seems more likely to cause problems (by swamping the collector) than fix them. We'll now send an inquiry the first time through the delay loop, and every 640 msec thereafter.
2011-09-17 00:25:27 +02:00
#define PGSTAT_MAX_WAIT_TIME 10000 /* Maximum time to wait for a stats
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
* file update; in milliseconds. */
Adjust pgstat message definitions so that the target message size is specified in just one place and adhered to exactly, rather than just more or less. A side effect is to increase PGSTAT_ACTIVITY_SIZE (maximum reported query length) from 256 to nearly 1000.
2004-06-26 18:32:04 +02:00
Remove debug logging for pgstat wait timeout. This reverts commit 79b2ee20c8a041a85dd230c4e787bef22edae57b, which proved to not be very informative; it looks like the "pgstat wait timeout" warnings in the buildfarm are just a symptom of running on heavily loaded machines, and there isn't any weird mechanism causing them to appear. To try to reduce the frequency of buildfarm failures from this effect, increase PGSTAT_MAX_WAIT_TIME from 5 seconds to 10. Also, arrange to not send a fresh inquiry message every single time through the loop, as that seems more likely to cause problems (by swamping the collector) than fix them. We'll now send an inquiry the first time through the delay loop, and every 640 msec thereafter.
2011-09-17 00:25:27 +02:00
#define PGSTAT_INQ_INTERVAL 640 /* How often to ping the collector for
* a new file; in milliseconds. */
Patch reverted because of random buildfarm failures: --------------------------------------------------------------------------- Delay write of pg_stats file to once every five minutes, during shutdown, or when requested by a backend: It changes so the file is only written once every 5 minutes (changeable of course, I just picked something) instead of once every half second. It's still written when the stats collector shuts down, just as before. And it is now also written on backend request. A backend requests a rewrite by simply sending a special stats message. It operates on the assumption that the backends aren't actually going to read the statistics file very often, compared to how frequent it's written today. Magnus Hagander
2006-05-30 04:35:39 +02:00
#define PGSTAT_RESTART_INTERVAL 60 /* How often to attempt to restart a
* failed statistics collector; in
* seconds. */
Adjust pgstat message definitions so that the target message size is specified in just one place and adhered to exactly, rather than just more or less. A side effect is to increase PGSTAT_ACTIVITY_SIZE (maximum reported query length) from 256 to nearly 1000.
2004-06-26 18:32:04 +02:00
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
#define PGSTAT_POLL_LOOP_COUNT (PGSTAT_MAX_WAIT_TIME / PGSTAT_RETRY_DELAY)
Remove debug logging for pgstat wait timeout. This reverts commit 79b2ee20c8a041a85dd230c4e787bef22edae57b, which proved to not be very informative; it looks like the "pgstat wait timeout" warnings in the buildfarm are just a symptom of running on heavily loaded machines, and there isn't any weird mechanism causing them to appear. To try to reduce the frequency of buildfarm failures from this effect, increase PGSTAT_MAX_WAIT_TIME from 5 seconds to 10. Also, arrange to not send a fresh inquiry message every single time through the loop, as that seems more likely to cause problems (by swamping the collector) than fix them. We'll now send an inquiry the first time through the delay loop, and every 640 msec thereafter.
2011-09-17 00:25:27 +02:00
#define PGSTAT_INQ_LOOP_COUNT (PGSTAT_INQ_INTERVAL / PGSTAT_RETRY_DELAY)
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
Adjust pgstat message definitions so that the target message size is specified in just one place and adhered to exactly, rather than just more or less. A side effect is to increase PGSTAT_ACTIVITY_SIZE (maximum reported query length) from 256 to nearly 1000.
2004-06-26 18:32:04 +02:00
/* ----------
* The initial size hints for the hash tables used in the collector.
* ----------
*/
#define PGSTAT_DB_HASH_SIZE 16
#define PGSTAT_TAB_HASH_SIZE 512
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
#define PGSTAT_FUNCTION_HASH_SIZE 512
Adjust pgstat message definitions so that the target message size is specified in just one place and adhered to exactly, rather than just more or less. A side effect is to increase PGSTAT_ACTIVITY_SIZE (maximum reported query length) from 256 to nearly 1000.
2004-06-26 18:32:04 +02:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
Fix handling of SIGCHLD, per recent pghackers discussion: on some platforms system(2) gets confused unless the signal handler is set to SIG_DFL, not SIG_IGN. pgstats.c now uses pqsignal() as it should, not signal(). Also, arrange for the stats collector process to show a reasonable ID in 'ps', rather than looking like a postmaster.
2001-08-04 02:14:43 +02:00
* GUC parameters
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
Simplify and rename some GUC variables, per various recent discussions: * stats_start_collector goes away; we always start the collector process, unless prevented by a problem with setting up the stats UDP socket. * stats_reset_on_server_start goes away; it seems useless in view of the availability of pg_stat_reset(). * stats_block_level and stats_row_level are merged into a single variable "track_counts", which controls all reports sent to the collector process. * stats_command_string is renamed to track_activities. * log_autovacuum is renamed to log_autovacuum_min_duration to better reflect its meaning. The log_autovacuum change is not a compatibility issue since it didn't exist before 8.3 anyway. The other changes need to be release-noted.
2007-09-24 05:12:23 +02:00
bool pgstat_track_activities = false;
bool pgstat_track_counts = false;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
int pgstat_track_functions = TRACK_FUNC_OFF;
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
int pgstat_track_activity_query_size = 1024;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Make the temporary directory for pgstat files configurable by the GUC variable stats_temp_directory, instead of requiring the admin to mount/symlink the pg_stat_tmp directory manually. For now the config variable is PGC_POSTMASTER. Room for further improvment that would allow it to be changed on-the-fly.
2008-08-15 10:37:41 +02:00
/* ----------
* Built from GUC parameter
* ----------
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
char *pgstat_stat_directory = NULL;
Make the temporary directory for pgstat files configurable by the GUC variable stats_temp_directory, instead of requiring the admin to mount/symlink the pg_stat_tmp directory manually. For now the config variable is PGC_POSTMASTER. Room for further improvment that would allow it to be changed on-the-fly.
2008-08-15 10:37:41 +02:00
char *pgstat_stat_filename = NULL;
char *pgstat_stat_tmpname = NULL;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/*
* BgWriter global statistics counters (unused in other processes).
* Stored directly in a stats message structure so it can be sent
* without needing to copy things around. We assume this inits to zeroes.
*/
PgStat_MsgBgWriter BgWriterStats;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
* Local data
* ----------
*/
Create typedef pgsocket for storing socket descriptors. This silences some warnings on Win64. Not using the proper SOCKET datatype was actually wrong on Win32 as well, but didn't cause any warnings there. Also create define PGINVALID_SOCKET to indicate an invalid/non-existing socket, instead of using a hardcoded -1 value.
2010-01-10 15:16:08 +01:00
NON_EXEC_STATIC pgsocket pgStatSock = PGINVALID_SOCKET;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
static struct sockaddr_storage pgStatAddr;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
static time_t last_pgstat_start_time;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Use setitimer() for stats file write, rather than do a gettimeofday() call for every stats packet read to adjust select() timeout. Other stylistic improvements.
2006-01-03 17:42:17 +01:00
static bool pgStatRunningInCollector = false;
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
/*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* Structures in which backends store per-table info that's waiting to be
* sent to the collector.
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* NOTE: once allocated, TabStatusArray structures are never moved or deleted
* for the life of the backend. Also, we zero out the t_id fields of the
* contained PgStat_TableStatus structs whenever they are not actively in use.
* This allows relcache pgstat_info pointers to be treated as long-lived data,
* avoiding repeated searches in pgstat_initstats() when a relation is
* repeatedly opened during a transaction.
*/
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
#define TABSTAT_QUANTUM 100 /* we alloc this many at a time */
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
typedef struct TabStatusArray
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
struct TabStatusArray *tsa_next; /* link to next array, if any */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
int tsa_used; /* # entries currently used */
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
PgStat_TableStatus tsa_entries[TABSTAT_QUANTUM]; /* per-table data */
Re-run pgindent with updated list of typedefs. (Updated README should avoid this problem in the future.)
2007-11-15 23:25:18 +01:00
} TabStatusArray;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
static TabStatusArray *pgStatTabList = NULL;
pgindent run.
2003-08-04 02:43:34 +02:00
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/*
* Backends store per-function info that's waiting to be sent to the collector
* in this hash table (indexed by function OID).
*/
static HTAB *pgStatFunctions = NULL;
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
/*
* Indicates if backend has some function stats that it hasn't yet
* sent to the collector.
*/
static bool have_function_stats = false;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/*
* Tuple insertion/deletion counts for an open transaction can't be propagated
* into PgStat_TableStatus counters until we know if it is going to commit
* or abort. Hence, we keep these counts in per-subxact structs that live
* in TopTransactionContext. This data structure is designed on the assumption
* that subxacts won't usually modify very many tables.
*/
typedef struct PgStat_SubXactStatus
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
int nest_level; /* subtransaction nest level */
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
struct PgStat_SubXactStatus *prev; /* higher-level subxact if any */
PgStat_TableXactStatus *first; /* head of list for this subxact */
Re-run pgindent with updated list of typedefs. (Updated README should avoid this problem in the future.)
2007-11-15 23:25:18 +01:00
} PgStat_SubXactStatus;
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
static PgStat_SubXactStatus *pgStatXactStack = NULL;
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
static int pgStatXactCommit = 0;
static int pgStatXactRollback = 0;
Rename I/O timing statistics columns to blk_read_time and blk_write_time. This seems more consistent with the pre-existing choices for names of other statistics columns. Rename assorted internal identifiers to match.
2012-04-30 00:13:33 +02:00
PgStat_Counter pgStatBlockReadTime = 0;
PgStat_Counter pgStatBlockWriteTime = 0;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/* Record that's written to 2PC state file when pgstat state is persisted */
typedef struct TwoPhasePgStatRecord
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
PgStat_Counter tuples_inserted; /* tuples inserted in xact */
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
PgStat_Counter tuples_updated; /* tuples updated in xact */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
PgStat_Counter tuples_deleted; /* tuples deleted in xact */
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
PgStat_Counter inserted_pre_trunc; /* tuples inserted prior to truncate */
PgStat_Counter updated_pre_trunc; /* tuples updated prior to truncate */
PgStat_Counter deleted_pre_trunc; /* tuples deleted prior to truncate */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Oid t_id; /* table's OID */
bool t_shared; /* is it a shared catalog? */
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
bool t_truncated; /* was the relation truncated? */
Re-run pgindent with updated list of typedefs. (Updated README should avoid this problem in the future.)
2007-11-15 23:25:18 +01:00
} TwoPhasePgStatRecord;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/*
* Info about current "snapshot" of stats file
*/
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
static MemoryContext pgStatLocalContext = NULL;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
static HTAB *pgStatDBHash = NULL;
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
static LocalPgBackendStatus *localBackendStatusTable = NULL;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
static int localNumBackends = 0;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
/*
* Cluster wide statistics, kept in the stats collector.
* Contains statistics that are not collected per database
* or per table.
*/
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
static PgStat_ArchiverStats archiverStats;
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
static PgStat_GlobalStats globalStats;
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/* Write request info for each database */
typedef struct DBWriteRequest
{
Oid databaseid; /* OID of the database to write */
TimestampTz request_time; /* timestamp of the last write request */
slist_node next;
} DBWriteRequest;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/* Latest statistics request times from backends */
static slist_head last_statrequests = SLIST_STATIC_INIT(last_statrequests);
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
static volatile bool need_exit = false;
Make stats_temp_directory PGC_SIGHUP, and document how it may cause a temporary "outage" of the statistics views. This requires making the stats collector respond to SIGHUP, like the other utility processes already did.
2008-08-25 17:11:01 +02:00
static volatile bool got_SIGHUP = false;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/*
* Total time charged to functions so far in the current backend.
* We use this to help separate "self" and "other" time charges.
* (We assume this initializes to zero.)
*/
static instr_time total_func_time;
Rearrange backend startup sequence so that ShmemIndexLock can become an LWLock instead of a spinlock. This hardly matters on Unix machines but should improve startup performance on Windows (or any port using EXEC_BACKEND). Per previous discussion.
2006-01-04 22:06:32 +01:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
* Local function forward declarations
* ----------
*/
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
#ifdef EXEC_BACKEND
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
static pid_t pgstat_forkexec(void);
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
#endif
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
Tweak __attribute__-wrapping macros for better pgindent results. This improves on commit bbfd7edae5aa5ad5553d3c7e102f2e450d4380d4 by making two simple changes: * pg_attribute_noreturn now takes parentheses, ie pg_attribute_noreturn(). Likewise pg_attribute_unused(), pg_attribute_packed(). This reduces pgindent's tendency to misformat declarations involving them. * attributes are now always attached to function declarations, not definitions. Previously some places were taking creative shortcuts, which were not merely candidates for bad misformatting by pgindent but often were outright wrong anyway. (It does little good to put a noreturn annotation where callers can't see it.) In any case, if we would like to believe that these macros can be used with non-gcc compilers, we should avoid gratuitous variance in usage patterns. I also went through and manually improved the formatting of a lot of declarations, and got rid of excessively repetitive (and now obsolete anyway) comments informing the reader what pg_attribute_printf is for.
2015-03-26 19:03:19 +01:00
NON_EXEC_STATIC void PgstatCollectorMain(int argc, char *argv[]) pg_attribute_noreturn();
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
static void pgstat_exit(SIGNAL_ARGS);
Flush any remaining statistics counts out to the collector at process exit. Without this, operations triggered during backend exit (such as temp table deletions) won't be counted ... which given heavy usage of temp tables can lead to pg_autovacuum falling way behind on the need to vacuum pg_class and pg_attribute. Per reports from Steve Crawford and others.
2005-04-01 01:20:49 +02:00
static void pgstat_beshutdown_hook(int code, Datum arg);
Make stats_temp_directory PGC_SIGHUP, and document how it may cause a temporary "outage" of the statistics views. This requires making the stats collector respond to SIGHUP, like the other utility processes already did.
2008-08-25 17:11:01 +02:00
static void pgstat_sighup_handler(SIGNAL_ARGS);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
static PgStat_StatDBEntry *pgstat_get_db_entry(Oid databaseid, bool create);
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
static PgStat_StatTabEntry *pgstat_get_tab_entry(PgStat_StatDBEntry *dbentry,
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
Oid tableoid, bool create);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
static void pgstat_write_statsfiles(bool permanent, bool allDbs);
static void pgstat_write_db_statsfile(PgStat_StatDBEntry *dbentry, bool permanent);
static HTAB *pgstat_read_statsfiles(Oid onlydb, bool permanent, bool deep);
static void pgstat_read_db_statsfile(Oid databaseid, HTAB *tabhash, HTAB *funchash, bool permanent);
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
static void backend_read_statsfile(void);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
static void pgstat_read_current_status(void);
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
static bool pgstat_write_statsfile_needed(void);
static bool pgstat_db_requested(Oid databaseid);
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
static void pgstat_send_tabstat(PgStat_MsgTabstat *tsmsg);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
static void pgstat_send_funcstats(void);
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
static HTAB *pgstat_collect_oids(Oid catalogid);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
static PgStat_TableStatus *get_tabstat_entry(Oid rel_id, bool isshared);
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
static void pgstat_setup_memcxt(void);
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
static void pgstat_setheader(PgStat_MsgHdr *hdr, StatMsgType mtype);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
static void pgstat_send(void *msg, int len);
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
static void pgstat_recv_inquiry(PgStat_MsgInquiry *msg, int len);
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
static void pgstat_recv_tabstat(PgStat_MsgTabstat *msg, int len);
static void pgstat_recv_tabpurge(PgStat_MsgTabpurge *msg, int len);
static void pgstat_recv_dropdb(PgStat_MsgDropdb *msg, int len);
static void pgstat_recv_resetcounter(PgStat_MsgResetcounter *msg, int len);
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
static void pgstat_recv_resetsharedcounter(PgStat_MsgResetsharedcounter *msg, int len);
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
static void pgstat_recv_resetsinglecounter(PgStat_MsgResetsinglecounter *msg, int len);
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
static void pgstat_recv_autovac(PgStat_MsgAutovacStart *msg, int len);
static void pgstat_recv_vacuum(PgStat_MsgVacuum *msg, int len);
static void pgstat_recv_analyze(PgStat_MsgAnalyze *msg, int len);
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
static void pgstat_recv_archiver(PgStat_MsgArchiver *msg, int len);
Re-run pgindent with updated list of typedefs. (Updated README should avoid this problem in the future.)
2007-11-15 23:25:18 +01:00
static void pgstat_recv_bgwriter(PgStat_MsgBgWriter *msg, int len);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
static void pgstat_recv_funcstat(PgStat_MsgFuncstat *msg, int len);
static void pgstat_recv_funcpurge(PgStat_MsgFuncpurge *msg, int len);
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
static void pgstat_recv_recoveryconflict(PgStat_MsgRecoveryConflict *msg, int len);
Add deadlock counter to pg_stat_database Adds a counter that tracks number of deadlocks that occurred in each database to pg_stat_database. Magnus Hagander, reviewed by Jaime Casanova
2012-01-26 15:58:19 +01:00
static void pgstat_recv_deadlock(PgStat_MsgDeadlock *msg, int len);
Track temporary file count and size in pg_stat_database Add counters for number and size of temporary files used for spill-to-disk queries for each database to the pg_stat_database view. Tomas Vondra, review by Magnus Hagander
2012-01-26 14:41:19 +01:00
static void pgstat_recv_tempfile(PgStat_MsgTempFile *msg, int len);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ------------------------------------------------------------
* Public functions called from postmaster follow
* ------------------------------------------------------------
*/
/* ----------
* pgstat_init() -
*
* Called from postmaster at startup. Create the resources required
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
* by the statistics collector process. If unable to do so, do not
* fail --- better to let the postmaster start with stats collection
* disabled.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
void
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgstat_init(void)
{
pgindent run.
2003-08-04 02:43:34 +02:00
ACCEPT_TYPE_ARG3 alen;
struct addrinfo *addrs = NULL,
*addr,
hints;
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
int ret;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
fd_set rset;
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
struct timeval tv;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
char test_byte;
int sel_res;
Add "retry another address" log message on statistics collector socket failure, to reduce confusion in the log file.
2006-04-20 12:51:32 +02:00
int tries = 0;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
#define TESTBYTEVAL ((char) 199)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Fix calculation of maximum statistics-message size. The PGSTAT_NUM_TABENTRIES macro should have been updated when new fields were added to struct PgStat_MsgTabstat in commit 644828908, but it wasn't. Fix that. Also, add a static assertion that we didn't overrun the intended size limit on stats messages. This will not necessarily catch every mistake in computing the maximum array size for stats messages, but it will catch ones that have practical consequences. (The assertion in fact doesn't complain about the aforementioned error in PGSTAT_NUM_TABENTRIES, because that was not big enough to cause the array length to increase.) No back-patch, as there's no actual bug in existing releases; this is just in the nature of future-proofing. Mark Dilger and Tom Lane
2014-01-03 03:45:47 +01:00
/*
* This static assertion verifies that we didn't mess up the calculations
* involved in selecting maximum payload sizes for our UDP messages.
* Because the only consequence of overrunning PGSTAT_MAX_MSG_SIZE would
* be silent performance loss from fragmentation, it seems worth having a
* compile-time cross-check that we didn't.
*/
StaticAssertStmt(sizeof(PgStat_Msg) <= PGSTAT_MAX_MSG_SIZE,
Ooops, should use double not single quotes in StaticAssertStmt(). That's what I get for testing this on an older compiler.
2014-01-03 03:54:20 +01:00
"maximum stats message size exceeds PGSTAT_MAX_MSG_SIZE");
Fix calculation of maximum statistics-message size. The PGSTAT_NUM_TABENTRIES macro should have been updated when new fields were added to struct PgStat_MsgTabstat in commit 644828908, but it wasn't. Fix that. Also, add a static assertion that we didn't overrun the intended size limit on stats messages. This will not necessarily catch every mistake in computing the maximum array size for stats messages, but it will catch ones that have practical consequences. (The assertion in fact doesn't complain about the aforementioned error in PGSTAT_NUM_TABENTRIES, because that was not big enough to cause the array length to increase.) No back-patch, as there's no actual bug in existing releases; this is just in the nature of future-proofing. Mark Dilger and Tom Lane
2014-01-03 03:45:47 +01:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Endeavor to make pgstats buffer process (a) safe and (b) useful. Make sure it exits immediately when collector process dies --- in old code, buffer process would hang around and compete with the new buffer process for packets. Make sure it doesn't block on writing the pipe when the collector falls more than a pipeload behind. Avoid leaking pgstats FDs into every backend.
2001-08-05 04:06:50 +02:00
* Create the UDP socket for sending and receiving statistic messages
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
hints.ai_flags = AI_PASSIVE;
Use AF_UNSPEC not PF_UNSPEC in getaddrinfo calls. According to the Single Unix Spec and assorted man pages, you're supposed to use the constants named AF_xxx when setting ai_family for a getaddrinfo call. In a few places we were using PF_xxx instead. Use of PF_xxx appears to be an ancient BSD convention that was not adopted by later standardization. On BSD and most later Unixen, it doesn't matter much because those constants have equivalent values anyway; but nonetheless this code is not per spec. In the same vein, replace PF_INET by AF_INET in one socket() call, which wasn't even consistent with the other socket() call in the same function let alone the remainder of our code. Per investigation of a Cygwin trouble report from Marco Atzeri. It's probably a long shot that this will fix his issue, but it's wrong in any case.
2014-04-16 19:20:54 +02:00
hints.ai_family = AF_UNSPEC;
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
hints.ai_socktype = SOCK_DGRAM;
hints.ai_protocol = 0;
hints.ai_addrlen = 0;
hints.ai_addr = NULL;
hints.ai_canonname = NULL;
hints.ai_next = NULL;
Clean up libpq's pollution of application namespace by renaming the exported routines of ip.c, md5.c, and fe-auth.c to begin with 'pg_'. Also get rid of the vestigial fe_setauthsvc/fe_getauthsvc routines altogether.
2005-10-17 18:24:20 +02:00
ret = pg_getaddrinfo_all("localhost", NULL, &hints, &addrs);
Have a go at fixing various outstanding portability issues in code that was modified for IPv6. Use a robust definition of struct sockaddr_storage, do a proper configure test to see if ss_len exists, don't assume that getnameinfo() will handle AF_UNIX sockets, don't trust getaddrinfo to return the protocol we ask for, etc. This incorporates several outstanding patches from Kurt Roeckx, but I'm to blame for anything that doesn't work ...
2003-07-24 01:30:41 +02:00
if (ret || !addrs)
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
{
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
ereport(LOG,
Have a go at fixing various outstanding portability issues in code that was modified for IPv6. Use a robust definition of struct sockaddr_storage, do a proper configure test to see if ss_len exists, don't assume that getnameinfo() will handle AF_UNIX sockets, don't trust getaddrinfo to return the protocol we ask for, etc. This incorporates several outstanding patches from Kurt Roeckx, but I'm to blame for anything that doesn't work ...
2003-07-24 01:30:41 +02:00
(errmsg("could not resolve \"localhost\": %s",
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
gai_strerror(ret))));
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
goto startup_failed;
}
pgindent run.
2003-08-04 02:43:34 +02:00
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
/*
Clean up libpq's pollution of application namespace by renaming the exported routines of ip.c, md5.c, and fe-auth.c to begin with 'pg_'. Also get rid of the vestigial fe_setauthsvc/fe_getauthsvc routines altogether.
2005-10-17 18:24:20 +02:00
* On some platforms, pg_getaddrinfo_all() may return multiple addresses
* only one of which will actually work (eg, both IPv6 and IPv4 addresses
* when kernel will reject IPv6). Worse, the failure may occur at the
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* bind() or perhaps even connect() stage. So we must loop through the
Clean up libpq's pollution of application namespace by renaming the exported routines of ip.c, md5.c, and fe-auth.c to begin with 'pg_'. Also get rid of the vestigial fe_setauthsvc/fe_getauthsvc routines altogether.
2005-10-17 18:24:20 +02:00
* results till we find a working combination. We will generate LOG
* messages, but no error, for bogus combinations.
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
*/
Have a go at fixing various outstanding portability issues in code that was modified for IPv6. Use a robust definition of struct sockaddr_storage, do a proper configure test to see if ss_len exists, don't assume that getnameinfo() will handle AF_UNIX sockets, don't trust getaddrinfo to return the protocol we ask for, etc. This incorporates several outstanding patches from Kurt Roeckx, but I'm to blame for anything that doesn't work ...
2003-07-24 01:30:41 +02:00
for (addr = addrs; addr; addr = addr->ai_next)
{
#ifdef HAVE_UNIX_SOCKETS
/* Ignore AF_UNIX sockets, if any are returned. */
if (addr->ai_family == AF_UNIX)
continue;
#endif
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
Add "retry another address" log message on statistics collector socket failure, to reduce confusion in the log file.
2006-04-20 12:51:32 +02:00
if (++tries > 1)
ereport(LOG,
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
(errmsg("trying another address for the statistics collector")));
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
/*
* Create the socket.
*/
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if ((pgStatSock = socket(addr->ai_family, SOCK_DGRAM, 0)) == PGINVALID_SOCKET)
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
{
ereport(LOG,
(errcode_for_socket_access(),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("could not create socket for statistics collector: %m")));
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
continue;
}
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Bind it to a kernel assigned port on localhost and get the assigned
* port via getsockname().
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
*/
if (bind(pgStatSock, addr->ai_addr, addr->ai_addrlen) < 0)
{
ereport(LOG,
(errcode_for_socket_access(),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("could not bind socket for statistics collector: %m")));
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
closesocket(pgStatSock);
Create typedef pgsocket for storing socket descriptors. This silences some warnings on Win64. Not using the proper SOCKET datatype was actually wrong on Win32 as well, but didn't cause any warnings there. Also create define PGINVALID_SOCKET to indicate an invalid/non-existing socket, instead of using a hardcoded -1 value.
2010-01-10 15:16:08 +01:00
pgStatSock = PGINVALID_SOCKET;
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
continue;
}
alen = sizeof(pgStatAddr);
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
if (getsockname(pgStatSock, (struct sockaddr *) & pgStatAddr, &alen) < 0)
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
{
ereport(LOG,
(errcode_for_socket_access(),
errmsg("could not get address of socket for statistics collector: %m")));
closesocket(pgStatSock);
Create typedef pgsocket for storing socket descriptors. This silences some warnings on Win64. Not using the proper SOCKET datatype was actually wrong on Win32 as well, but didn't cause any warnings there. Also create define PGINVALID_SOCKET to indicate an invalid/non-existing socket, instead of using a hardcoded -1 value.
2010-01-10 15:16:08 +01:00
pgStatSock = PGINVALID_SOCKET;
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
continue;
}
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Connect the socket to its own address. This saves a few cycles by
* not having to respecify the target address on every send. This also
* provides a kernel-level check that only packets from this same
* address will be received.
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
*/
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
if (connect(pgStatSock, (struct sockaddr *) & pgStatAddr, alen) < 0)
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
{
ereport(LOG,
(errcode_for_socket_access(),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("could not connect socket for statistics collector: %m")));
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
closesocket(pgStatSock);
Create typedef pgsocket for storing socket descriptors. This silences some warnings on Win64. Not using the proper SOCKET datatype was actually wrong on Win32 as well, but didn't cause any warnings there. Also create define PGINVALID_SOCKET to indicate an invalid/non-existing socket, instead of using a hardcoded -1 value.
2010-01-10 15:16:08 +01:00
pgStatSock = PGINVALID_SOCKET;
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
continue;
}
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Try to send and receive a one-byte test message on the socket. This
* is to catch situations where the socket can be created but will not
* actually pass data (for instance, because kernel packet filtering
* rules prevent it).
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
*/
test_byte = TESTBYTEVAL;
Ensure that we retry rather than erroring out when send() or recv() return EINTR; the stats code was failing to do this and so were a couple of places in the postmaster. The stats code assumed that recv() could not return EINTR if a preceding select() showed the socket to be read-ready, but this is demonstrably false with our Windows implementation of recv(), and it may not be the case on all Unix variants either. I think this explains the intermittent stats regression test failures we've been seeing, as well as reports of stats collector instability under high load on Windows. Backpatch as far as 8.0.
2006-07-16 20:17:14 +02:00
retry1:
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
if (send(pgStatSock, &test_byte, 1, 0) != 1)
{
Ensure that we retry rather than erroring out when send() or recv() return EINTR; the stats code was failing to do this and so were a couple of places in the postmaster. The stats code assumed that recv() could not return EINTR if a preceding select() showed the socket to be read-ready, but this is demonstrably false with our Windows implementation of recv(), and it may not be the case on all Unix variants either. I think this explains the intermittent stats regression test failures we've been seeing, as well as reports of stats collector instability under high load on Windows. Backpatch as far as 8.0.
2006-07-16 20:17:14 +02:00
if (errno == EINTR)
goto retry1; /* if interrupted, just retry */
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
ereport(LOG,
(errcode_for_socket_access(),
errmsg("could not send test message on socket for statistics collector: %m")));
closesocket(pgStatSock);
Create typedef pgsocket for storing socket descriptors. This silences some warnings on Win64. Not using the proper SOCKET datatype was actually wrong on Win32 as well, but didn't cause any warnings there. Also create define PGINVALID_SOCKET to indicate an invalid/non-existing socket, instead of using a hardcoded -1 value.
2010-01-10 15:16:08 +01:00
pgStatSock = PGINVALID_SOCKET;
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
continue;
}
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* There could possibly be a little delay before the message can be
* received. We arbitrarily allow up to half a second before deciding
* it's broken.
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
*/
for (;;) /* need a loop to handle EINTR */
{
FD_ZERO(&rset);
pgindent run for 9.0, second run
2010-07-06 21:19:02 +02:00
FD_SET(pgStatSock, &rset);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
tv.tv_sec = 0;
tv.tv_usec = 500000;
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
sel_res = select(pgStatSock + 1, &rset, NULL, NULL, &tv);
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
if (sel_res >= 0 || errno != EINTR)
break;
}
if (sel_res < 0)
{
ereport(LOG,
(errcode_for_socket_access(),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("select() failed in statistics collector: %m")));
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
closesocket(pgStatSock);
Create typedef pgsocket for storing socket descriptors. This silences some warnings on Win64. Not using the proper SOCKET datatype was actually wrong on Win32 as well, but didn't cause any warnings there. Also create define PGINVALID_SOCKET to indicate an invalid/non-existing socket, instead of using a hardcoded -1 value.
2010-01-10 15:16:08 +01:00
pgStatSock = PGINVALID_SOCKET;
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
continue;
}
if (sel_res == 0 || !FD_ISSET(pgStatSock, &rset))
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* This is the case we actually think is likely, so take pains to
* give a specific message for it.
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
*
* errno will not be set meaningfully here, so don't use it.
*/
ereport(LOG,
Ensure that 'disabling statistics collector' is logged in all failure paths of pgstat_init. Responds to confusion exhibited by Christoph Haller.
2004-12-20 20:17:56 +01:00
(errcode(ERRCODE_CONNECTION_FAILURE),
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
errmsg("test message did not get through on socket for statistics collector")));
closesocket(pgStatSock);
Create typedef pgsocket for storing socket descriptors. This silences some warnings on Win64. Not using the proper SOCKET datatype was actually wrong on Win32 as well, but didn't cause any warnings there. Also create define PGINVALID_SOCKET to indicate an invalid/non-existing socket, instead of using a hardcoded -1 value.
2010-01-10 15:16:08 +01:00
pgStatSock = PGINVALID_SOCKET;
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
continue;
}
test_byte++; /* just make sure variable is changed */
Ensure that we retry rather than erroring out when send() or recv() return EINTR; the stats code was failing to do this and so were a couple of places in the postmaster. The stats code assumed that recv() could not return EINTR if a preceding select() showed the socket to be read-ready, but this is demonstrably false with our Windows implementation of recv(), and it may not be the case on all Unix variants either. I think this explains the intermittent stats regression test failures we've been seeing, as well as reports of stats collector instability under high load on Windows. Backpatch as far as 8.0.
2006-07-16 20:17:14 +02:00
retry2:
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
if (recv(pgStatSock, &test_byte, 1, 0) != 1)
{
Ensure that we retry rather than erroring out when send() or recv() return EINTR; the stats code was failing to do this and so were a couple of places in the postmaster. The stats code assumed that recv() could not return EINTR if a preceding select() showed the socket to be read-ready, but this is demonstrably false with our Windows implementation of recv(), and it may not be the case on all Unix variants either. I think this explains the intermittent stats regression test failures we've been seeing, as well as reports of stats collector instability under high load on Windows. Backpatch as far as 8.0.
2006-07-16 20:17:14 +02:00
if (errno == EINTR)
goto retry2; /* if interrupted, just retry */
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
ereport(LOG,
(errcode_for_socket_access(),
errmsg("could not receive test message on socket for statistics collector: %m")));
closesocket(pgStatSock);
Create typedef pgsocket for storing socket descriptors. This silences some warnings on Win64. Not using the proper SOCKET datatype was actually wrong on Win32 as well, but didn't cause any warnings there. Also create define PGINVALID_SOCKET to indicate an invalid/non-existing socket, instead of using a hardcoded -1 value.
2010-01-10 15:16:08 +01:00
pgStatSock = PGINVALID_SOCKET;
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
continue;
}
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
if (test_byte != TESTBYTEVAL) /* strictly paranoia ... */
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
{
ereport(LOG,
Ensure that 'disabling statistics collector' is logged in all failure paths of pgstat_init. Responds to confusion exhibited by Christoph Haller.
2004-12-20 20:17:56 +01:00
(errcode(ERRCODE_INTERNAL_ERROR),
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
errmsg("incorrect test message transmission on socket for statistics collector")));
closesocket(pgStatSock);
Create typedef pgsocket for storing socket descriptors. This silences some warnings on Win64. Not using the proper SOCKET datatype was actually wrong on Win32 as well, but didn't cause any warnings there. Also create define PGINVALID_SOCKET to indicate an invalid/non-existing socket, instead of using a hardcoded -1 value.
2010-01-10 15:16:08 +01:00
pgStatSock = PGINVALID_SOCKET;
Before deciding we can use a socket for statistics collection, test to ensure that it actually passes data. This catches cases such as a kernel packet filter rule that makes the socket useless. Andrew Dunstan
2004-03-23 00:55:29 +01:00
continue;
}
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
/* If we get here, we have a working socket */
break;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
/* Did we find a working address? */
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (!addr || pgStatSock == PGINVALID_SOCKET)
Allow postmaster to start up anyway when PGSTAT code fails to initialize, per recent discussion on pghackers. Also, fix PGSTAT code to report errors via elog, not scribbling directly on stderr.
2002-04-03 02:27:25 +02:00
goto startup_failed;
Endeavor to make pgstats buffer process (a) safe and (b) useful. Make sure it exits immediately when collector process dies --- in old code, buffer process would hang around and compete with the new buffer process for packets. Make sure it doesn't block on writing the pipe when the collector falls more than a pipeload behind. Avoid leaking pgstats FDs into every backend.
2001-08-05 04:06:50 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Set the socket to non-blocking IO. This ensures that if the collector
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
* falls behind, statistics messages will be discarded; backends won't
* block waiting to send messages to the collector.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Kerberos fixes from Magnus Hagander --- in theory Kerberos 5 auth should work on Windows now. Also, rename set_noblock to pg_set_noblock; since it is included in libpq, the former name polluted application namespace.
2005-03-25 01:34:31 +01:00
if (!pg_set_noblock(pgStatSock))
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
ereport(LOG,
(errcode_for_socket_access(),
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
errmsg("could not set statistics collector socket to nonblocking mode: %m")));
Allow postmaster to start up anyway when PGSTAT code fails to initialize, per recent discussion on pghackers. Also, fix PGSTAT code to report errors via elog, not scribbling directly on stderr.
2002-04-03 02:27:25 +02:00
goto startup_failed;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Clean up libpq's pollution of application namespace by renaming the exported routines of ip.c, md5.c, and fe-auth.c to begin with 'pg_'. Also get rid of the vestigial fe_setauthsvc/fe_getauthsvc routines altogether.
2005-10-17 18:24:20 +02:00
pg_freeaddrinfo_all(hints.ai_family, addrs);
Make creation of statistics collection socket more robust, by allowing it to try additional addresses returned from getaddrinfo() if the first one fails at the bind() or connect() steps. Per yesterday's discussion.
2003-11-15 18:24:07 +01:00
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
return;
Allow postmaster to start up anyway when PGSTAT code fails to initialize, per recent discussion on pghackers. Also, fix PGSTAT code to report errors via elog, not scribbling directly on stderr.
2002-04-03 02:27:25 +02:00
startup_failed:
Ensure that 'disabling statistics collector' is logged in all failure paths of pgstat_init. Responds to confusion exhibited by Christoph Haller.
2004-12-20 20:17:56 +01:00
ereport(LOG,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(errmsg("disabling statistics collector for lack of working socket")));
Ensure that 'disabling statistics collector' is logged in all failure paths of pgstat_init. Responds to confusion exhibited by Christoph Haller.
2004-12-20 20:17:56 +01:00
Have a go at fixing various outstanding portability issues in code that was modified for IPv6. Use a robust definition of struct sockaddr_storage, do a proper configure test to see if ss_len exists, don't assume that getnameinfo() will handle AF_UNIX sockets, don't trust getaddrinfo to return the protocol we ask for, etc. This incorporates several outstanding patches from Kurt Roeckx, but I'm to blame for anything that doesn't work ...
2003-07-24 01:30:41 +02:00
if (addrs)
Clean up libpq's pollution of application namespace by renaming the exported routines of ip.c, md5.c, and fe-auth.c to begin with 'pg_'. Also get rid of the vestigial fe_setauthsvc/fe_getauthsvc routines altogether.
2005-10-17 18:24:20 +02:00
pg_freeaddrinfo_all(hints.ai_family, addrs);
IPv6 cleanups. Kurt Roeckx Andrew Dunstan
2003-06-12 09:36:51 +02:00
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock != PGINVALID_SOCKET)
Use closesocket() for all socket/pipe closing, because Win32 requires it, and map that to close() on Unix.
2003-04-25 03:24:00 +02:00
closesocket(pgStatSock);
Create typedef pgsocket for storing socket descriptors. This silences some warnings on Win64. Not using the proper SOCKET datatype was actually wrong on Win32 as well, but didn't cause any warnings there. Also create define PGINVALID_SOCKET to indicate an invalid/non-existing socket, instead of using a hardcoded -1 value.
2010-01-10 15:16:08 +01:00
pgStatSock = PGINVALID_SOCKET;
Allow postmaster to start up anyway when PGSTAT code fails to initialize, per recent discussion on pghackers. Also, fix PGSTAT code to report errors via elog, not scribbling directly on stderr.
2002-04-03 02:27:25 +02:00
Simplify and rename some GUC variables, per various recent discussions: * stats_start_collector goes away; we always start the collector process, unless prevented by a problem with setting up the stats UDP socket. * stats_reset_on_server_start goes away; it seems useless in view of the availability of pg_stat_reset(). * stats_block_level and stats_row_level are merged into a single variable "track_counts", which controls all reports sent to the collector process. * stats_command_string is renamed to track_activities. * log_autovacuum is renamed to log_autovacuum_min_duration to better reflect its meaning. The log_autovacuum change is not a compatibility issue since it didn't exist before 8.3 anyway. The other changes need to be release-noted.
2007-09-24 05:12:23 +02:00
/*
* Adjust GUC variables to suppress useless activity, and for debugging
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* purposes (seeing track_counts off is a clue that we failed here). We
* use PGC_S_OVERRIDE because there is no point in trying to turn it back
* on from postgresql.conf without a restart.
Simplify and rename some GUC variables, per various recent discussions: * stats_start_collector goes away; we always start the collector process, unless prevented by a problem with setting up the stats UDP socket. * stats_reset_on_server_start goes away; it seems useless in view of the availability of pg_stat_reset(). * stats_block_level and stats_row_level are merged into a single variable "track_counts", which controls all reports sent to the collector process. * stats_command_string is renamed to track_activities. * log_autovacuum is renamed to log_autovacuum_min_duration to better reflect its meaning. The log_autovacuum change is not a compatibility issue since it didn't exist before 8.3 anyway. The other changes need to be release-noted.
2007-09-24 05:12:23 +02:00
*/
SetConfigOption("track_counts", "off", PGC_INTERNAL, PGC_S_OVERRIDE);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/*
* subroutine for pgstat_reset_all
*/
static void
pgstat_reset_remove_files(const char *directory)
{
DIR *dir;
struct dirent *entry;
char fname[MAXPGPATH];
Fix removal of files in pgstats directories Instead of deleting all files in stats_temp_directory and the permanent directory on a crash, only remove those files that match the pattern of files we actually write in them, to avoid possibly clobbering existing unrelated contents of the temporary directory. Per complaint from Jeff Janes, and subsequent discussion, starting at message CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com Also, fix a bug in the same routine to avoid removing files from the permanent directory twice (instead of once from that directory and then from the temporary directory), also per report from Jeff Janes, in message CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com
2013-08-19 23:48:17 +02:00
dir = AllocateDir(directory);
while ((entry = ReadDir(dir, directory)) != NULL)
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
{
Be more wary of unwanted whitespace in pgstat_reset_remove_files(). sscanf isn't the easiest thing to use for exact pattern checks ... also, don't use strncmp where strcmp will do.
2013-08-20 01:36:04 +02:00
int nchars;
Oid tmp_oid;
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
Fix removal of files in pgstats directories Instead of deleting all files in stats_temp_directory and the permanent directory on a crash, only remove those files that match the pattern of files we actually write in them, to avoid possibly clobbering existing unrelated contents of the temporary directory. Per complaint from Jeff Janes, and subsequent discussion, starting at message CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com Also, fix a bug in the same routine to avoid removing files from the permanent directory twice (instead of once from that directory and then from the temporary directory), also per report from Jeff Janes, in message CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com
2013-08-19 23:48:17 +02:00
/*
* Skip directory entries that don't match the file names we write.
* See get_dbstat_filename for the database-specific pattern.
*/
Be more wary of unwanted whitespace in pgstat_reset_remove_files(). sscanf isn't the easiest thing to use for exact pattern checks ... also, don't use strncmp where strcmp will do.
2013-08-20 01:36:04 +02:00
if (strncmp(entry->d_name, "global.", 7) == 0)
nchars = 7;
else
Fix removal of files in pgstats directories Instead of deleting all files in stats_temp_directory and the permanent directory on a crash, only remove those files that match the pattern of files we actually write in them, to avoid possibly clobbering existing unrelated contents of the temporary directory. Per complaint from Jeff Janes, and subsequent discussion, starting at message CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com Also, fix a bug in the same routine to avoid removing files from the permanent directory twice (instead of once from that directory and then from the temporary directory), also per report from Jeff Janes, in message CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com
2013-08-19 23:48:17 +02:00
{
Be more wary of unwanted whitespace in pgstat_reset_remove_files(). sscanf isn't the easiest thing to use for exact pattern checks ... also, don't use strncmp where strcmp will do.
2013-08-20 01:36:04 +02:00
nchars = 0;
(void) sscanf(entry->d_name, "db_%u.%n",
&tmp_oid, &nchars);
if (nchars <= 0)
continue;
/* %u allows leading whitespace, so reject that */
if (strchr("0123456789", entry->d_name[3]) == NULL)
Fix removal of files in pgstats directories Instead of deleting all files in stats_temp_directory and the permanent directory on a crash, only remove those files that match the pattern of files we actually write in them, to avoid possibly clobbering existing unrelated contents of the temporary directory. Per complaint from Jeff Janes, and subsequent discussion, starting at message CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com Also, fix a bug in the same routine to avoid removing files from the permanent directory twice (instead of once from that directory and then from the temporary directory), also per report from Jeff Janes, in message CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com
2013-08-19 23:48:17 +02:00
continue;
}
Be more wary of unwanted whitespace in pgstat_reset_remove_files(). sscanf isn't the easiest thing to use for exact pattern checks ... also, don't use strncmp where strcmp will do.
2013-08-20 01:36:04 +02:00
if (strcmp(entry->d_name + nchars, "tmp") != 0 &&
strcmp(entry->d_name + nchars, "stat") != 0)
Fix removal of files in pgstats directories Instead of deleting all files in stats_temp_directory and the permanent directory on a crash, only remove those files that match the pattern of files we actually write in them, to avoid possibly clobbering existing unrelated contents of the temporary directory. Per complaint from Jeff Janes, and subsequent discussion, starting at message CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com Also, fix a bug in the same routine to avoid removing files from the permanent directory twice (instead of once from that directory and then from the temporary directory), also per report from Jeff Janes, in message CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com
2013-08-19 23:48:17 +02:00
continue;
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
Fix removal of files in pgstats directories Instead of deleting all files in stats_temp_directory and the permanent directory on a crash, only remove those files that match the pattern of files we actually write in them, to avoid possibly clobbering existing unrelated contents of the temporary directory. Per complaint from Jeff Janes, and subsequent discussion, starting at message CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com Also, fix a bug in the same routine to avoid removing files from the permanent directory twice (instead of once from that directory and then from the temporary directory), also per report from Jeff Janes, in message CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com
2013-08-19 23:48:17 +02:00
snprintf(fname, MAXPGPATH, "%s/%s", directory,
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
entry->d_name);
unlink(fname);
}
FreeDir(dir);
}
Autovacuum loose end mop-up. Provide autovacuum-specific vacuum cost delay and limit, both as global GUCs and as table-specific entries in pg_autovacuum. stats_reset_on_server_start is now OFF by default, but a reset is forced if we did WAL replay. XID-wrap vacuums do not ANALYZE, but do FREEZE if it's a template database. Alvaro Herrera
2005-08-11 23:11:50 +02:00
/*
* pgstat_reset_all() -
*
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* Remove the stats files. This is currently used only if WAL
Autovacuum loose end mop-up. Provide autovacuum-specific vacuum cost delay and limit, both as global GUCs and as table-specific entries in pg_autovacuum. stats_reset_on_server_start is now OFF by default, but a reset is forced if we did WAL replay. XID-wrap vacuums do not ANALYZE, but do FREEZE if it's a template database. Alvaro Herrera
2005-08-11 23:11:50 +02:00
* recovery is needed after a crash.
*/
void
pgstat_reset_all(void)
{
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgstat_reset_remove_files(pgstat_stat_directory);
pgstat_reset_remove_files(PGSTAT_STAT_PERMANENT_DIRECTORY);
Autovacuum loose end mop-up. Provide autovacuum-specific vacuum cost delay and limit, both as global GUCs and as table-specific entries in pg_autovacuum. stats_reset_on_server_start is now OFF by default, but a reset is forced if we did WAL replay. XID-wrap vacuums do not ANALYZE, but do FREEZE if it's a template database. Alvaro Herrera
2005-08-11 23:11:50 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
#ifdef EXEC_BACKEND
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
/*
Final rearrangement of main postgresql child process (ie. BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to closely mimic (the soon to be provided) Win32 CreateProcess equivalent calls. Claudio Natoli
2004-01-07 00:15:22 +01:00
* pgstat_forkexec() -
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
*
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
* Format up the arglist for, then fork and exec, statistics collector process
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
*/
Final rearrangement of main postgresql child process (ie. BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to closely mimic (the soon to be provided) Win32 CreateProcess equivalent calls. Claudio Natoli
2004-01-07 00:15:22 +01:00
static pid_t
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
pgstat_forkexec(void)
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
{
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
char *av[10];
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
int ac = 0;
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
av[ac++] = "postgres";
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
av[ac++] = "--forkcol";
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
av[ac++] = NULL; /* filled in by postmaster_forkexec */
av[ac] = NULL;
Assert(ac < lengthof(av));
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
return postmaster_forkexec(ac, av);
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
}
Pgindent run for 8.0.
2004-08-29 07:07:03 +02:00
#endif /* EXEC_BACKEND */
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
Simplify and rename some GUC variables, per various recent discussions: * stats_start_collector goes away; we always start the collector process, unless prevented by a problem with setting up the stats UDP socket. * stats_reset_on_server_start goes away; it seems useless in view of the availability of pg_stat_reset(). * stats_block_level and stats_row_level are merged into a single variable "track_counts", which controls all reports sent to the collector process. * stats_command_string is renamed to track_activities. * log_autovacuum is renamed to log_autovacuum_min_duration to better reflect its meaning. The log_autovacuum change is not a compatibility issue since it didn't exist before 8.3 anyway. The other changes need to be release-noted.
2007-09-24 05:12:23 +02:00
/*
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* pgstat_start() -
*
* Called from postmaster at startup or after an existing collector
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
* died. Attempt to fire up a fresh statistics collector.
Allow postmaster to start up anyway when PGSTAT code fails to initialize, per recent discussion on pghackers. Also, fix PGSTAT code to report errors via elog, not scribbling directly on stderr.
2002-04-03 02:27:25 +02:00
*
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
* Returns PID of child process, or 0 if fail.
*
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
* Note: if fail, we will be called again from the postmaster main loop.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
int
Fix getopt-vs-init_ps_display problem by copying original argv[] info, per suggestion from Peter. Simplify several APIs by transmitting the original argv location directly from main.c to ps_status.c, instead of passing it down through several levels of subroutines.
2001-10-21 05:25:36 +02:00
pgstat_start(void)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
time_t curtime;
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
pid_t pgStatPid;
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
Added GUC configuration options to control access statistics. Jan
2001-07-05 17:19:40 +02:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* Check that the socket is there, else pgstat_init failed and we can do
* nothing useful.
Added GUC configuration options to control access statistics. Jan
2001-07-05 17:19:40 +02:00
*/
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
return 0;
Added GUC configuration options to control access statistics. Jan
2001-07-05 17:19:40 +02:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Do nothing if too soon since last collector start. This is a safety
* valve to protect against continuous respawn attempts if the collector
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* is dying immediately at launch. Note that since we will be re-called
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* from the postmaster main loop, we will get another chance later.
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
*/
curtime = time(NULL);
if ((unsigned int) (curtime - last_pgstat_start_time) <
(unsigned int) PGSTAT_RESTART_INTERVAL)
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
return 0;
Tweak stats collector start logic so that we will not try to spawn a new stats collector oftener than once a minute. Per gripe from Erik Walthinsen 4/25/03.
2003-04-26 04:57:14 +02:00
last_pgstat_start_time = curtime;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
* Okay, fork off the collector.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Final rearrangement of main postgresql child process (ie. BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to closely mimic (the soon to be provided) Win32 CreateProcess equivalent calls. Claudio Natoli
2004-01-07 00:15:22 +01:00
#ifdef EXEC_BACKEND
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
switch ((pgStatPid = pgstat_forkexec()))
Final rearrangement of main postgresql child process (ie. BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to closely mimic (the soon to be provided) Win32 CreateProcess equivalent calls. Claudio Natoli
2004-01-07 00:15:22 +01:00
#else
Use fork_process() to avoid some fork()-related boilerplate code when forking the stats collector child process.
2005-04-08 02:55:07 +02:00
switch ((pgStatPid = fork_process()))
Final rearrangement of main postgresql child process (ie. BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to closely mimic (the soon to be provided) Win32 CreateProcess equivalent calls. Claudio Natoli
2004-01-07 00:15:22 +01:00
#endif
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
case -1:
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
ereport(LOG,
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
(errmsg("could not fork statistics collector: %m")));
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
return 0;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Final rearrangement of main postgresql child process (ie. BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to closely mimic (the soon to be provided) Win32 CreateProcess equivalent calls. Claudio Natoli
2004-01-07 00:15:22 +01:00
#ifndef EXEC_BACKEND
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
case 0:
Final rearrangement of main postgresql child process (ie. BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to closely mimic (the soon to be provided) Win32 CreateProcess equivalent calls. Claudio Natoli
2004-01-07 00:15:22 +01:00
/* in postmaster child ... */
Commonalize process startup code. Move common code, that was duplicated in every postmaster child/every standalone process, into two functions in miscinit.c. Not only does that already result in a fair amount of net code reduction but it also makes it much easier to remove more duplication in the future. The prime motivation wasn't code deduplication though, but easier addition of new common code.
2015-01-13 13:12:37 +01:00
InitPostmasterChild();
Separate out bgwriter code into a logically separate module, rather than being random pieces of other files. Give bgwriter responsibility for all checkpoint activity (other than a post-recovery checkpoint); so this child process absorbs the functionality of the former transient checkpoint and shutdown subprocesses. While at it, create an actual include file for postmaster.c, which for some reason never had its own file before.
2004-05-30 00:48:23 +02:00
/* Close the postmaster's sockets */
Create a built-in log rotation program, so that we no longer have to recommend that people go get Apache's rotatelogs program. Additional benefits are that configuration is done through GUC, rather than externally, and that the postmaster can monitor the log rotator and restart it after failure (though we certainly hope that won't happen often). Andreas Pflug, some rework by Tom Lane.
2004-08-06 01:32:13 +02:00
ClosePostmasterPorts(false);
Final rearrangement of main postgresql child process (ie. BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to closely mimic (the soon to be provided) Win32 CreateProcess equivalent calls. Claudio Natoli
2004-01-07 00:15:22 +01:00
/* Drop our connection to postmaster's shared memory, as well */
Make it easy to detach completely from shared memory. The new function dsm_detach_all() can be used either by postmaster children that don't wish to take any risk of accidentally corrupting shared memory; or by forked children of regular backends with the same need. This patch also updates the postmaster children that already do PGSharedMemoryDetach() to do dsm_detach_all() as well. Per discussion with Tom Lane.
2014-03-18 12:58:53 +01:00
dsm_detach_all();
Final rearrangement of main postgresql child process (ie. BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to closely mimic (the soon to be provided) Win32 CreateProcess equivalent calls. Claudio Natoli
2004-01-07 00:15:22 +01:00
PGSharedMemoryDetach();
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
PgstatCollectorMain(0, NULL);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
break;
Final rearrangement of main postgresql child process (ie. BackendFork/SSDataBase/pgstat) startup, to allow fork/exec calls to closely mimic (the soon to be provided) Win32 CreateProcess equivalent calls. Claudio Natoli
2004-01-07 00:15:22 +01:00
#endif
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
default:
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
return (int) pgStatPid;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
/* shouldn't get here */
return 0;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
void
allow_immediate_pgstat_restart(void)
Allow the pgstat process to restart immediately after a receiving SIGQUIT signal, rather than waiting for PGSTAT_RESTART_INTERVAL.
2007-03-22 20:53:31 +01:00
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
last_pgstat_start_time = 0;
Allow the pgstat process to restart immediately after a receiving SIGQUIT signal, rather than waiting for PGSTAT_RESTART_INTERVAL.
2007-03-22 20:53:31 +01:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ------------------------------------------------------------
* Public functions used by backends follow
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
*------------------------------------------------------------
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
/* ----------
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
* pgstat_report_stat() -
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*
Implement rate-limiting logic on how often backends will attempt to send messages to the stats collector. This avoids the problem that enabling stats_row_level for autovacuum has a significant overhead for short read-only transactions, as noted by Arjen van der Meijden. We can avoid an extra gettimeofday call by piggybacking on the one done for WAL-logging xact commit or abort (although that doesn't help read-only transactions, since they don't WAL-log anything). In my proposal for this, I noted that we could change the WAL log entries for commit/abort to record full TimestampTz precision, instead of only time_t as at present. That's not done in this patch, but will be committed separately.
2007-04-30 05:23:49 +02:00
* Called from tcop/postgres.c to send the so far collected per-table
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
* and function usage statistics to the collector. Note that this is
* called only when not within a transaction, so it is fair to use
* transaction stop time as an approximation of current time.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
void
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
pgstat_report_stat(bool force)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/* we assume this inits to all zeroes: */
static const PgStat_TableCounts all_zeroes;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
static TimestampTz last_report = 0;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
Implement rate-limiting logic on how often backends will attempt to send messages to the stats collector. This avoids the problem that enabling stats_row_level for autovacuum has a significant overhead for short read-only transactions, as noted by Arjen van der Meijden. We can avoid an extra gettimeofday call by piggybacking on the one done for WAL-logging xact commit or abort (although that doesn't help read-only transactions, since they don't WAL-log anything). In my proposal for this, I noted that we could change the WAL log entries for commit/abort to record full TimestampTz precision, instead of only time_t as at present. That's not done in this patch, but will be committed separately.
2007-04-30 05:23:49 +02:00
TimestampTz now;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
PgStat_MsgTabstat regular_msg;
PgStat_MsgTabstat shared_msg;
TabStatusArray *tsa;
int i;
Implement rate-limiting logic on how often backends will attempt to send messages to the stats collector. This avoids the problem that enabling stats_row_level for autovacuum has a significant overhead for short read-only transactions, as noted by Arjen van der Meijden. We can avoid an extra gettimeofday call by piggybacking on the one done for WAL-logging xact commit or abort (although that doesn't help read-only transactions, since they don't WAL-log anything). In my proposal for this, I noted that we could change the WAL log entries for commit/abort to record full TimestampTz precision, instead of only time_t as at present. That's not done in this patch, but will be committed separately.
2007-04-30 05:23:49 +02:00
/* Don't expend a clock check if nothing to do */
Fix possible failure to send final transaction counts to stats collector. Normally, we suppress sending a tabstats message to the collector unless there were some actual table stats to send. However, during backend exit we should force out the message if there are any transaction commit/abort counts to send, else the session's last few commit/abort counts will never get reported at all. We had logic for this, but the short-circuit test at the top of pgstat_report_stat() ignored the "force" flag, with the consequence that session-ending transactions that touched no database-local tables would not get counted. Seems to be an oversight in my commit 641912b4d17fd214a5e5bae4e7bb9ddbc28b144b, which added the "force" flag. That was back in 8.3, so back-patch to all supported versions.
2013-02-07 20:44:00 +01:00
if ((pgStatTabList == NULL || pgStatTabList->tsa_used == 0) &&
Smooth reporting of commit/rollback statistics. If a connection committed or rolled back any transactions within a PGSTAT_STAT_INTERVAL pacing interval without accessing any tables, the reporting of those statistics would be held up until the connection closed or until it ended a PGSTAT_STAT_INTERVAL interval in which it had accessed a table. This could result in under- reporting of transactions for an extended period, followed by a spike in reported transactions. While this is arguably a bug, the impact is minimal, primarily affecting, and being affected by, monitoring software. It might cause more confusion than benefit to change the existing behavior in released stable branches, so apply only to master and the 9.4 beta. Gurjeet Singh, with review and editing by Kevin Grittner, incorporating suggested changes from Abhijit Menon-Sen and Tom Lane.
2014-07-02 22:20:30 +02:00
pgStatXactCommit == 0 && pgStatXactRollback == 0 &&
!have_function_stats)
Implement rate-limiting logic on how often backends will attempt to send messages to the stats collector. This avoids the problem that enabling stats_row_level for autovacuum has a significant overhead for short read-only transactions, as noted by Arjen van der Meijden. We can avoid an extra gettimeofday call by piggybacking on the one done for WAL-logging xact commit or abort (although that doesn't help read-only transactions, since they don't WAL-log anything). In my proposal for this, I noted that we could change the WAL log entries for commit/abort to record full TimestampTz precision, instead of only time_t as at present. That's not done in this patch, but will be committed separately.
2007-04-30 05:23:49 +02:00
return;
/*
* Don't send a message unless it's been at least PGSTAT_STAT_INTERVAL
Fix oversight in my patch of yesterday: forgot to ensure that stats would still be forced out at backend exit.
2007-04-30 18:37:08 +02:00
* msec since we last sent one, or the caller wants to force stats out.
Implement rate-limiting logic on how often backends will attempt to send messages to the stats collector. This avoids the problem that enabling stats_row_level for autovacuum has a significant overhead for short read-only transactions, as noted by Arjen van der Meijden. We can avoid an extra gettimeofday call by piggybacking on the one done for WAL-logging xact commit or abort (although that doesn't help read-only transactions, since they don't WAL-log anything). In my proposal for this, I noted that we could change the WAL log entries for commit/abort to record full TimestampTz precision, instead of only time_t as at present. That's not done in this patch, but will be committed separately.
2007-04-30 05:23:49 +02:00
*/
now = GetCurrentTransactionStopTimestamp();
Fix oversight in my patch of yesterday: forgot to ensure that stats would still be forced out at backend exit.
2007-04-30 18:37:08 +02:00
if (!force &&
!TimestampDifferenceExceeds(last_report, now, PGSTAT_STAT_INTERVAL))
Implement rate-limiting logic on how often backends will attempt to send messages to the stats collector. This avoids the problem that enabling stats_row_level for autovacuum has a significant overhead for short read-only transactions, as noted by Arjen van der Meijden. We can avoid an extra gettimeofday call by piggybacking on the one done for WAL-logging xact commit or abort (although that doesn't help read-only transactions, since they don't WAL-log anything). In my proposal for this, I noted that we could change the WAL log entries for commit/abort to record full TimestampTz precision, instead of only time_t as at present. That's not done in this patch, but will be committed separately.
2007-04-30 05:23:49 +02:00
return;
last_report = now;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* Scan through the TabStatusArray struct(s) to find tables that actually
* have counts, and build messages to send. We have to separate shared
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* relations from regular ones because the databaseid field in the message
* header has to depend on that.
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
*/
regular_msg.m_databaseid = MyDatabaseId;
shared_msg.m_databaseid = InvalidOid;
regular_msg.m_nentries = 0;
shared_msg.m_nentries = 0;
for (tsa = pgStatTabList; tsa != NULL; tsa = tsa->tsa_next)
{
for (i = 0; i < tsa->tsa_used; i++)
{
PgStat_TableStatus *entry = &tsa->tsa_entries[i];
PgStat_MsgTabstat *this_msg;
PgStat_TableEntry *this_ent;
/* Shouldn't have any pending transaction-dependent counts */
Assert(entry->trans == NULL);
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* Ignore entries that didn't accumulate any actual counts, such
* as indexes that were opened by the planner but not used.
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
*/
if (memcmp(&entry->t_counts, &all_zeroes,
sizeof(PgStat_TableCounts)) == 0)
continue;
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/*
* OK, insert data into the appropriate message, and send if full.
*/
this_msg = entry->t_shared ? &shared_msg : &regular_msg;
this_ent = &this_msg->m_entry[this_msg->m_nentries];
this_ent->t_id = entry->t_id;
memcpy(&this_ent->t_counts, &entry->t_counts,
sizeof(PgStat_TableCounts));
if (++this_msg->m_nentries >= PGSTAT_NUM_TABENTRIES)
{
pgstat_send_tabstat(this_msg);
this_msg->m_nentries = 0;
}
}
/* zero out TableStatus structs after use */
MemSet(tsa->tsa_entries, 0,
tsa->tsa_used * sizeof(PgStat_TableStatus));
tsa->tsa_used = 0;
}
/*
Smooth reporting of commit/rollback statistics. If a connection committed or rolled back any transactions within a PGSTAT_STAT_INTERVAL pacing interval without accessing any tables, the reporting of those statistics would be held up until the connection closed or until it ended a PGSTAT_STAT_INTERVAL interval in which it had accessed a table. This could result in under- reporting of transactions for an extended period, followed by a spike in reported transactions. While this is arguably a bug, the impact is minimal, primarily affecting, and being affected by, monitoring software. It might cause more confusion than benefit to change the existing behavior in released stable branches, so apply only to master and the 9.4 beta. Gurjeet Singh, with review and editing by Kevin Grittner, incorporating suggested changes from Abhijit Menon-Sen and Tom Lane.
2014-07-02 22:20:30 +02:00
* Send partial messages. Make sure that any pending xact commit/abort
* gets counted, even if there are no table stats to send.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
if (regular_msg.m_nentries > 0 ||
Smooth reporting of commit/rollback statistics. If a connection committed or rolled back any transactions within a PGSTAT_STAT_INTERVAL pacing interval without accessing any tables, the reporting of those statistics would be held up until the connection closed or until it ended a PGSTAT_STAT_INTERVAL interval in which it had accessed a table. This could result in under- reporting of transactions for an extended period, followed by a spike in reported transactions. While this is arguably a bug, the impact is minimal, primarily affecting, and being affected by, monitoring software. It might cause more confusion than benefit to change the existing behavior in released stable branches, so apply only to master and the 9.4 beta. Gurjeet Singh, with review and editing by Kevin Grittner, incorporating suggested changes from Abhijit Menon-Sen and Tom Lane.
2014-07-02 22:20:30 +02:00
pgStatXactCommit > 0 || pgStatXactRollback > 0)
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
pgstat_send_tabstat(&regular_msg);
if (shared_msg.m_nentries > 0)
pgstat_send_tabstat(&shared_msg);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/* Now, send function statistics */
pgstat_send_funcstats();
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
}
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/*
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
* Subroutine for pgstat_report_stat: finish and send a tabstat message
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
*/
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
static void
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
pgstat_send_tabstat(PgStat_MsgTabstat *tsmsg)
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
int n;
int len;
Avoid unnecessary work when stats collection is disabled. Tighten search loop in pgstat_initstats. Per report from Gavin Sherry.
2003-08-12 18:21:18 +02:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/* It's unlikely we'd get here with no socket, but maybe not impossible */
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
return;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/*
Clear I/O timing counters after sending them to the stats collector. This oversight caused the reported times to accumulate in an O(N^2) fashion the longer a backend runs.
2012-04-28 21:11:13 +02:00
* Report and reset accumulated xact commit/rollback and I/O timings
* whenever we send a normal tabstat message
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
*/
if (OidIsValid(tsmsg->m_databaseid))
{
Avoid unnecessary work when stats collection is disabled. Tighten search loop in pgstat_initstats. Per report from Gavin Sherry.
2003-08-12 18:21:18 +02:00
tsmsg->m_xact_commit = pgStatXactCommit;
tsmsg->m_xact_rollback = pgStatXactRollback;
Rename I/O timing statistics columns to blk_read_time and blk_write_time. This seems more consistent with the pre-existing choices for names of other statistics columns. Rename assorted internal identifiers to match.
2012-04-30 00:13:33 +02:00
tsmsg->m_block_read_time = pgStatBlockReadTime;
tsmsg->m_block_write_time = pgStatBlockWriteTime;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
pgStatXactCommit = 0;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgStatXactRollback = 0;
Rename I/O timing statistics columns to blk_read_time and blk_write_time. This seems more consistent with the pre-existing choices for names of other statistics columns. Rename assorted internal identifiers to match.
2012-04-30 00:13:33 +02:00
pgStatBlockReadTime = 0;
pgStatBlockWriteTime = 0;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
}
else
{
tsmsg->m_xact_commit = 0;
tsmsg->m_xact_rollback = 0;
Rename I/O timing statistics columns to blk_read_time and blk_write_time. This seems more consistent with the pre-existing choices for names of other statistics columns. Rename assorted internal identifiers to match.
2012-04-30 00:13:33 +02:00
tsmsg->m_block_read_time = 0;
tsmsg->m_block_write_time = 0;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
n = tsmsg->m_nentries;
len = offsetof(PgStat_MsgTabstat, m_entry[0]) +
n * sizeof(PgStat_TableEntry);
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
pgstat_setheader(&tsmsg->m_hdr, PGSTAT_MTYPE_TABSTAT);
pgstat_send(tsmsg, len);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/*
* Subroutine for pgstat_report_stat: populate and send a function stat message
*/
static void
pgstat_send_funcstats(void)
{
/* we assume this inits to all zeroes: */
static const PgStat_FunctionCounts all_zeroes;
PgStat_MsgFuncstat msg;
PgStat_BackendFunctionEntry *entry;
HASH_SEQ_STATUS fstat;
if (pgStatFunctions == NULL)
return;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_FUNCSTAT);
msg.m_databaseid = MyDatabaseId;
msg.m_nentries = 0;
hash_seq_init(&fstat, pgStatFunctions);
while ((entry = (PgStat_BackendFunctionEntry *) hash_seq_search(&fstat)) != NULL)
{
PgStat_FunctionEntry *m_ent;
/* Skip it if no counts accumulated since last time */
if (memcmp(&entry->f_counts, &all_zeroes,
sizeof(PgStat_FunctionCounts)) == 0)
continue;
/* need to convert format of time accumulators */
m_ent = &msg.m_entry[msg.m_nentries];
m_ent->f_id = entry->f_id;
m_ent->f_numcalls = entry->f_counts.f_numcalls;
Converge all SQL-level statistics timing values to float8 milliseconds. This patch adjusts the core statistics views to match the decision already taken for pg_stat_statements, that values representing elapsed time should be represented as float8 and measured in milliseconds. By using float8, we are no longer tied to a specific maximum precision of timing data. (Internally, it's still microseconds, but we could now change that without needing changes at the SQL level.) The columns affected are pg_stat_bgwriter.checkpoint_write_time pg_stat_bgwriter.checkpoint_sync_time pg_stat_database.blk_read_time pg_stat_database.blk_write_time pg_stat_user_functions.total_time pg_stat_user_functions.self_time pg_stat_xact_user_functions.total_time pg_stat_xact_user_functions.self_time The first four of these are new in 9.2, so there is no compatibility issue from changing them. The others require a release note comment that they are now double precision (and can show a fractional part) rather than bigint as before; also their underlying statistics functions now match the column definitions, instead of returning bigint microseconds.
2012-04-30 20:02:47 +02:00
m_ent->f_total_time = INSTR_TIME_GET_MICROSEC(entry->f_counts.f_total_time);
m_ent->f_self_time = INSTR_TIME_GET_MICROSEC(entry->f_counts.f_self_time);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
if (++msg.m_nentries >= PGSTAT_NUM_FUNCENTRIES)
{
pgstat_send(&msg, offsetof(PgStat_MsgFuncstat, m_entry[0]) +
msg.m_nentries * sizeof(PgStat_FunctionEntry));
msg.m_nentries = 0;
}
/* reset the entry's counts */
MemSet(&entry->f_counts, 0, sizeof(PgStat_FunctionCounts));
}
if (msg.m_nentries > 0)
pgstat_send(&msg, offsetof(PgStat_MsgFuncstat, m_entry[0]) +
msg.m_nentries * sizeof(PgStat_FunctionEntry));
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
have_function_stats = false;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
* pgstat_vacuum_stat() -
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*
* Will tell the collector about objects he can get rid of.
* ----------
*/
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
void
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
pgstat_vacuum_stat(void)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
HTAB *htab;
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
PgStat_MsgTabpurge msg;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
PgStat_MsgFuncpurge f_msg;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
HASH_SEQ_STATUS hstat;
PgStat_StatDBEntry *dbentry;
PgStat_StatTabEntry *tabentry;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
PgStat_StatFuncEntry *funcentry;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
int len;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
return;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If not done for this transaction, read the statistics collector stats
* file into some hash tables.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
backend_read_statsfile();
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
* Read pg_database and make a list of OIDs of all existing databases
*/
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
htab = pgstat_collect_oids(DatabaseRelationId);
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
/*
* Search the database hash table for dead databases and tell the
* collector to drop them.
*/
hash_seq_init(&hstat, pgStatDBHash);
while ((dbentry = (PgStat_StatDBEntry *) hash_seq_search(&hstat)) != NULL)
{
Oid dbid = dbentry->databaseid;
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
CHECK_FOR_INTERRUPTS();
Avoid losing track of data for shared tables in pgstats. Report by Michael Fuhr, patch from Tom Lane after a messier suggestion by me.
2007-06-07 20:53:17 +02:00
/* the DB entry for shared tables (with InvalidOid) is never dropped */
if (OidIsValid(dbid) &&
hash_search(htab, (void *) &dbid, HASH_FIND, NULL) == NULL)
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
pgstat_drop_database(dbid);
}
/* Clean up */
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
hash_destroy(htab);
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
/*
* Lookup our own database entry; if not found, nothing more to do.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
dbentry = (PgStat_StatDBEntry *) hash_search(pgStatDBHash,
(void *) &MyDatabaseId,
HASH_FIND, NULL);
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
if (dbentry == NULL || dbentry->tables == NULL)
return;
/*
* Similarly to above, make a list of all known relations in this DB.
*/
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
htab = pgstat_collect_oids(RelationRelationId);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
* Initialize our messages table counter to zero
*/
msg.m_nentries = 0;
/*
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
* Check for all tables listed in stats hashtable if they still exist.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
hash_seq_init(&hstat, dbentry->tables);
Further cleanup of dynahash.c API, in pursuit of portability and readability. Bizarre '(long *) TRUE' return convention is gone, in favor of just raising an error internally in dynahash.c when we detect hashtable corruption. HashTableWalk is gone, in favor of using hash_seq_search directly, since it had no hope of working with non-LONGALIGNable datatypes. Simplify some other code that was made undesirably grotty by promixity to HashTableWalk.
2001-10-05 19:28:13 +02:00
while ((tabentry = (PgStat_StatTabEntry *) hash_seq_search(&hstat)) != NULL)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
Oid tabid = tabentry->tableid;
CHECK_FOR_INTERRUPTS();
if (hash_search(htab, (void *) &tabid, HASH_FIND, NULL) != NULL)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
continue;
/*
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
* Not there, so add this table's Oid to the message
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
msg.m_tableid[msg.m_nentries++] = tabid;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
* If the message is full, send it out and reinitialize to empty
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
if (msg.m_nentries >= PGSTAT_NUM_TABPURGE)
{
Fix unportable, non-spec-compliant use of offsetof() with a nonconstant member offset.
2001-11-26 23:31:08 +01:00
len = offsetof(PgStat_MsgTabpurge, m_tableid[0])
pgindent run.
2002-09-04 22:31:48 +02:00
+msg.m_nentries * sizeof(Oid);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_TABPURGE);
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
msg.m_databaseid = MyDatabaseId;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgstat_send(&msg, len);
msg.m_nentries = 0;
}
}
/*
* Send the rest
*/
if (msg.m_nentries > 0)
{
Fix unportable, non-spec-compliant use of offsetof() with a nonconstant member offset.
2001-11-26 23:31:08 +01:00
len = offsetof(PgStat_MsgTabpurge, m_tableid[0])
pgindent run.
2002-09-04 22:31:48 +02:00
+msg.m_nentries * sizeof(Oid);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_TABPURGE);
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
msg.m_databaseid = MyDatabaseId;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgstat_send(&msg, len);
}
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
/* Clean up */
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
hash_destroy(htab);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/*
Teach pgstat_vacuum_stat to not bother scanning pg_proc in the common case where no function stats entries exist. Partial response to Pavel's observation that small VACUUM operations are noticeably slower in CVS HEAD than 8.3.
2008-12-08 16:44:54 +01:00
* Now repeat the above steps for functions. However, we needn't bother
* in the common case where no function stats are being collected.
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
*/
Teach pgstat_vacuum_stat to not bother scanning pg_proc in the common case where no function stats entries exist. Partial response to Pavel's observation that small VACUUM operations are noticeably slower in CVS HEAD than 8.3.
2008-12-08 16:44:54 +01:00
if (dbentry->functions != NULL &&
hash_get_num_entries(dbentry->functions) > 0)
{
htab = pgstat_collect_oids(ProcedureRelationId);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
Teach pgstat_vacuum_stat to not bother scanning pg_proc in the common case where no function stats entries exist. Partial response to Pavel's observation that small VACUUM operations are noticeably slower in CVS HEAD than 8.3.
2008-12-08 16:44:54 +01:00
pgstat_setheader(&f_msg.m_hdr, PGSTAT_MTYPE_FUNCPURGE);
f_msg.m_databaseid = MyDatabaseId;
f_msg.m_nentries = 0;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
Teach pgstat_vacuum_stat to not bother scanning pg_proc in the common case where no function stats entries exist. Partial response to Pavel's observation that small VACUUM operations are noticeably slower in CVS HEAD than 8.3.
2008-12-08 16:44:54 +01:00
hash_seq_init(&hstat, dbentry->functions);
while ((funcentry = (PgStat_StatFuncEntry *) hash_seq_search(&hstat)) != NULL)
{
Oid funcid = funcentry->functionid;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
Teach pgstat_vacuum_stat to not bother scanning pg_proc in the common case where no function stats entries exist. Partial response to Pavel's observation that small VACUUM operations are noticeably slower in CVS HEAD than 8.3.
2008-12-08 16:44:54 +01:00
CHECK_FOR_INTERRUPTS();
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
Teach pgstat_vacuum_stat to not bother scanning pg_proc in the common case where no function stats entries exist. Partial response to Pavel's observation that small VACUUM operations are noticeably slower in CVS HEAD than 8.3.
2008-12-08 16:44:54 +01:00
if (hash_search(htab, (void *) &funcid, HASH_FIND, NULL) != NULL)
continue;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
Teach pgstat_vacuum_stat to not bother scanning pg_proc in the common case where no function stats entries exist. Partial response to Pavel's observation that small VACUUM operations are noticeably slower in CVS HEAD than 8.3.
2008-12-08 16:44:54 +01:00
/*
* Not there, so add this function's Oid to the message
*/
f_msg.m_functionid[f_msg.m_nentries++] = funcid;
/*
* If the message is full, send it out and reinitialize to empty
*/
if (f_msg.m_nentries >= PGSTAT_NUM_FUNCPURGE)
{
len = offsetof(PgStat_MsgFuncpurge, m_functionid[0])
+f_msg.m_nentries * sizeof(Oid);
pgstat_send(&f_msg, len);
f_msg.m_nentries = 0;
}
}
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/*
Teach pgstat_vacuum_stat to not bother scanning pg_proc in the common case where no function stats entries exist. Partial response to Pavel's observation that small VACUUM operations are noticeably slower in CVS HEAD than 8.3.
2008-12-08 16:44:54 +01:00
* Send the rest
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
*/
Teach pgstat_vacuum_stat to not bother scanning pg_proc in the common case where no function stats entries exist. Partial response to Pavel's observation that small VACUUM operations are noticeably slower in CVS HEAD than 8.3.
2008-12-08 16:44:54 +01:00
if (f_msg.m_nentries > 0)
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
{
len = offsetof(PgStat_MsgFuncpurge, m_functionid[0])
+f_msg.m_nentries * sizeof(Oid);
pgstat_send(&f_msg, len);
}
Teach pgstat_vacuum_stat to not bother scanning pg_proc in the common case where no function stats entries exist. Partial response to Pavel's observation that small VACUUM operations are noticeably slower in CVS HEAD than 8.3.
2008-12-08 16:44:54 +01:00
hash_destroy(htab);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
}
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
}
/* ----------
* pgstat_collect_oids() -
*
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
* Collect the OIDs of all objects listed in the specified system catalog
* into a temporary hash table. Caller should hash_destroy the result
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* when done with it. (However, we make the table in CurrentMemoryContext
Avoid memory leak if pgstat_vacuum_stat is interrupted partway through. The temporary hash tables made by pgstat_collect_oids should be allocated in a short-term memory context, which is not the default behavior of hash_create. Noted while looking through hash_create calls in connection with Robert Haas' recent complaint. This is a pre-existing bug, but it doesn't seem important enough to back-patch. The hash table is not so large that it would matter unless this happened many times within a session, which seems quite unlikely.
2009-12-27 20:40:07 +01:00
* so that it will be freed properly in event of an error.)
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
* ----------
*/
static HTAB *
pgstat_collect_oids(Oid catalogid)
{
HTAB *htab;
HASHCTL hash_ctl;
Relation rel;
HeapScanDesc scan;
HeapTuple tup;
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans. SnapshotNow scans have the undesirable property that, in the face of concurrent updates, the scan can fail to see either the old or the new versions of the row. In many cases, we work around this by requiring DDL operations to hold AccessExclusiveLock on the object being modified; in some cases, the existing locking is inadequate and random failures occur as a result. This commit doesn't change anything related to locking, but will hopefully pave the way to allowing lock strength reductions in the future. The major issue has held us back from making this change in the past is that taking an MVCC snapshot is significantly more expensive than using a static special snapshot such as SnapshotNow. However, testing of various worst-case scenarios reveals that this problem is not severe except under fairly extreme workloads. To mitigate those problems, we avoid retaking the MVCC snapshot for each new scan; instead, we take a new snapshot only when invalidation messages have been processed. The catcache machinery already requires that invalidation messages be sent before releasing the related heavyweight lock; else other backends might rely on locally-cached data rather than scanning the catalog at all. Thus, making snapshot reuse dependent on the same guarantees shouldn't break anything that wasn't already subtly broken. Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
Snapshot snapshot;
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
memset(&hash_ctl, 0, sizeof(hash_ctl));
hash_ctl.keysize = sizeof(Oid);
hash_ctl.entrysize = sizeof(Oid);
Avoid memory leak if pgstat_vacuum_stat is interrupted partway through. The temporary hash tables made by pgstat_collect_oids should be allocated in a short-term memory context, which is not the default behavior of hash_create. Noted while looking through hash_create calls in connection with Robert Haas' recent complaint. This is a pre-existing bug, but it doesn't seem important enough to back-patch. The hash table is not so large that it would matter unless this happened many times within a session, which seems quite unlikely.
2009-12-27 20:40:07 +01:00
hash_ctl.hcxt = CurrentMemoryContext;
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
htab = hash_create("Temporary table of OIDs",
PGSTAT_TAB_HASH_SIZE,
&hash_ctl,
Improve hash_create's API for selecting simple-binary-key hash functions. Previously, if you wanted anything besides C-string hash keys, you had to specify a custom hashing function to hash_create(). Nearly all such callers were specifying tag_hash or oid_hash; which is tedious, and rather error-prone, since a caller could easily miss the opportunity to optimize by using hash_uint32 when appropriate. Replace this with a design whereby callers using simple binary-data keys just specify HASH_BLOBS and don't need to mess with specific support functions. hash_create() itself will take care of optimizing when the key size is four bytes. This nets out saving a few hundred bytes of code space, and offers a measurable performance improvement in tidbitmap.c (which was not exploiting the opportunity to use hash_uint32 for its 4-byte keys). There might be some wins elsewhere too, I didn't analyze closely. In future we could look into offering a similar optimized hashing function for 8-byte keys. Under this design that could be done in a centralized and machine-independent fashion, whereas getting it right for keys of platform-dependent sizes would've been notationally painful before. For the moment, the old way still works fine, so as not to break source code compatibility for loadable modules. Eventually we might want to remove tag_hash and friends from the exported API altogether, since there's no real need for them to be explicitly referenced from outside dynahash.c. Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
rel = heap_open(catalogid, AccessShareLock);
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans. SnapshotNow scans have the undesirable property that, in the face of concurrent updates, the scan can fail to see either the old or the new versions of the row. In many cases, we work around this by requiring DDL operations to hold AccessExclusiveLock on the object being modified; in some cases, the existing locking is inadequate and random failures occur as a result. This commit doesn't change anything related to locking, but will hopefully pave the way to allowing lock strength reductions in the future. The major issue has held us back from making this change in the past is that taking an MVCC snapshot is significantly more expensive than using a static special snapshot such as SnapshotNow. However, testing of various worst-case scenarios reveals that this problem is not severe except under fairly extreme workloads. To mitigate those problems, we avoid retaking the MVCC snapshot for each new scan; instead, we take a new snapshot only when invalidation messages have been processed. The catcache machinery already requires that invalidation messages be sent before releasing the related heavyweight lock; else other backends might rely on locally-cached data rather than scanning the catalog at all. Thus, making snapshot reuse dependent on the same guarantees shouldn't break anything that wasn't already subtly broken. Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
snapshot = RegisterSnapshot(GetLatestSnapshot());
scan = heap_beginscan(rel, snapshot, 0, NULL);
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
while ((tup = heap_getnext(scan, ForwardScanDirection)) != NULL)
{
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
Oid thisoid = HeapTupleGetOid(tup);
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
CHECK_FOR_INTERRUPTS();
(void) hash_search(htab, (void *) &thisoid, HASH_ENTER, NULL);
}
heap_endscan(scan);
Use an MVCC snapshot, rather than SnapshotNow, for catalog scans. SnapshotNow scans have the undesirable property that, in the face of concurrent updates, the scan can fail to see either the old or the new versions of the row. In many cases, we work around this by requiring DDL operations to hold AccessExclusiveLock on the object being modified; in some cases, the existing locking is inadequate and random failures occur as a result. This commit doesn't change anything related to locking, but will hopefully pave the way to allowing lock strength reductions in the future. The major issue has held us back from making this change in the past is that taking an MVCC snapshot is significantly more expensive than using a static special snapshot such as SnapshotNow. However, testing of various worst-case scenarios reveals that this problem is not severe except under fairly extreme workloads. To mitigate those problems, we avoid retaking the MVCC snapshot for each new scan; instead, we take a new snapshot only when invalidation messages have been processed. The catcache machinery already requires that invalidation messages be sent before releasing the related heavyweight lock; else other backends might rely on locally-cached data rather than scanning the catalog at all. Thus, making snapshot reuse dependent on the same guarantees shouldn't break anything that wasn't already subtly broken. Patch by me. Review by Michael Paquier and Andres Freund.
2013-07-02 15:47:01 +02:00
UnregisterSnapshot(snapshot);
Fix a performance problem in databases with large numbers of tables (or other types of pg_class entry): the function pgstat_vacuum_tabstat, invoked during VACUUM startup, had runtime proportional to the number of stats table entries times the number of pg_class rows; in other words O(N^2) if the stats collector's information is reasonably complete. Replace list searching with a hash table to bring it back to O(N) behavior. Per report from kim at myemma.com. Back-patch as far as 8.1; 8.0 and before use different coding here.
2007-01-12 00:06:03 +01:00
heap_close(rel, AccessShareLock);
return htab;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
/* ----------
* pgstat_drop_database() -
*
* Tell the collector that we just dropped a database.
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
* (If the message gets lost, we will still clean the dead DB eventually
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
* via future invocations of pgstat_vacuum_stat().)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
Call pgstat_drop_database during DROP DATABASE, so that any stats file entries for the victim database go away sooner rather than later. We already did the equivalent thing at the per-relation level, not sure why it's not been done for whole databases. With this change, pgstat_vacuum_tabstat should usually not find anything to do; though we still need it as a backstop in case DROPDB or TABPURGE messages get lost under load.
2007-02-09 17:12:19 +01:00
void
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgstat_drop_database(Oid databaseid)
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
PgStat_MsgDropdb msg;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
return;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_DROPDB);
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
msg.m_databaseid = databaseid;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgstat_send(&msg, sizeof(msg));
}
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
/* ----------
* pgstat_drop_relation() -
*
* Tell the collector that we just dropped a relation.
* (If the message gets lost, we will still clean the dead entry eventually
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
* via future invocations of pgstat_vacuum_stat().)
Remove the pgstat_drop_relation() call from smgr_internal_unlink(), because we don't know at that point which relation OID to tell pgstat to forget. The code was passing the relfilenode, which is incorrect, and could possibly cause some other relation's stats to be zeroed out. While we could try to clean this up, it seems much simpler and more reliable to let the next invocation of pgstat_vacuum_tabstat() fix things; which indeed is how it worked before I introduced the buggy code into 8.1.3 and later :-(. Problem noticed by Itagaki Takahiro, fix is per subsequent discussion.
2007-07-09 00:23:16 +02:00
*
* Currently not used for lack of any good place to call it; we rely
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
* entirely on pgstat_vacuum_stat() to clean out stats for dead rels.
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
* ----------
*/
Remove the pgstat_drop_relation() call from smgr_internal_unlink(), because we don't know at that point which relation OID to tell pgstat to forget. The code was passing the relfilenode, which is incorrect, and could possibly cause some other relation's stats to be zeroed out. While we could try to clean this up, it seems much simpler and more reliable to let the next invocation of pgstat_vacuum_tabstat() fix things; which indeed is how it worked before I introduced the buggy code into 8.1.3 and later :-(. Problem noticed by Itagaki Takahiro, fix is per subsequent discussion.
2007-07-09 00:23:16 +02:00
#ifdef NOT_USED
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
void
pgstat_drop_relation(Oid relid)
{
PgStat_MsgTabpurge msg;
int len;
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
return;
msg.m_tableid[0] = relid;
msg.m_nentries = 1;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
len = offsetof(PgStat_MsgTabpurge, m_tableid[0]) +sizeof(Oid);
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_TABPURGE);
msg.m_databaseid = MyDatabaseId;
pgstat_send(&msg, len);
}
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
#endif /* NOT_USED */
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
* pgstat_reset_counters() -
*
* Tell the statistics collector to reset counters for our database.
Use GRANT system to manage access to sensitive functions Now that pg_dump will properly dump out any ACL changes made to functions which exist in pg_catalog, switch to using the GRANT system to manage access to those functions. This means removing 'if (!superuser()) ereport()' checks from the functions themselves and then REVOKEing EXECUTE right from 'public' for these functions in system_views.sql. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
*
* Permission checking for this function is managed through the normal
* GRANT system.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
void
pgstat_reset_counters(void)
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
PgStat_MsgResetcounter msg;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
return;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_RESETCOUNTER);
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
msg.m_databaseid = MyDatabaseId;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgstat_send(&msg, sizeof(msg));
}
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
/* ----------
* pgstat_reset_shared_counters() -
*
* Tell the statistics collector to reset cluster-wide shared counters.
Use GRANT system to manage access to sensitive functions Now that pg_dump will properly dump out any ACL changes made to functions which exist in pg_catalog, switch to using the GRANT system to manage access to those functions. This means removing 'if (!superuser()) ereport()' checks from the functions themselves and then REVOKEing EXECUTE right from 'public' for these functions in system_views.sql. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
*
* Permission checking for this function is managed through the normal
* GRANT system.
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
* ----------
*/
void
pgstat_reset_shared_counters(const char *target)
{
PgStat_MsgResetsharedcounter msg;
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
return;
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
if (strcmp(target, "archiver") == 0)
msg.m_resettarget = RESET_ARCHIVER;
else if (strcmp(target, "bgwriter") == 0)
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
msg.m_resettarget = RESET_BGWRITER;
else
ereport(ERROR,
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
(errcode(ERRCODE_INVALID_PARAMETER_VALUE),
errmsg("unrecognized reset target: \"%s\"", target),
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
errhint("Target must be \"archiver\" or \"bgwriter\".")));
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_RESETSHAREDCOUNTER);
pgstat_send(&msg, sizeof(msg));
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
/* ----------
* pgstat_reset_single_counter() -
*
* Tell the statistics collector to reset a single counter.
Use GRANT system to manage access to sensitive functions Now that pg_dump will properly dump out any ACL changes made to functions which exist in pg_catalog, switch to using the GRANT system to manage access to those functions. This means removing 'if (!superuser()) ereport()' checks from the functions themselves and then REVOKEing EXECUTE right from 'public' for these functions in system_views.sql. Reviews by Alexander Korotkov, Jose Luis Tallon
2016-04-07 03:45:32 +02:00
*
* Permission checking for this function is managed through the normal
* GRANT system.
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
* ----------
*/
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
void
pgstat_reset_single_counter(Oid objoid, PgStat_Single_Reset_Type type)
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
{
PgStat_MsgResetsinglecounter msg;
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
return;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_RESETSINGLECOUNTER);
msg.m_databaseid = MyDatabaseId;
msg.m_resettype = type;
msg.m_objectid = objoid;
pgstat_send(&msg, sizeof(msg));
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/* ----------
* pgstat_report_autovac() -
*
* Called from autovacuum.c to report startup of an autovacuum process.
* We are called before InitPostgres is done, so can't rely on MyDatabaseId;
* the db OID must be passed in, instead.
* ----------
*/
void
pgstat_report_autovac(Oid dboid)
{
PgStat_MsgAutovacStart msg;
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
return;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_AUTOVAC_START);
msg.m_databaseid = dboid;
msg.m_start_time = GetCurrentTimestamp();
pgstat_send(&msg, sizeof(msg));
}
/* ---------
* pgstat_report_vacuum() -
*
* Tell the collector about the table we just vacuumed.
* ---------
*/
void
Fix VACUUM's reporting of dead-tuple counts to the stats collector. Historically, VACUUM has just reported its new_rel_tuples estimate (the same thing it puts into pg_class.reltuples) to the stats collector. That number counts both live and dead-but-not-yet-reclaimable tuples. This behavior may once have been right, but modern versions of the pgstats code track live and dead tuple counts separately, so putting the total into n_live_tuples and zero into n_dead_tuples is surely pretty bogus. Fix it to report live and dead tuple counts separately. This doesn't really do much for situations where updating transactions commit concurrently with a VACUUM scan (possibly causing double-counting or omission of the tuples they add or delete); but it's clearly an improvement over what we were doing before. Hari Babu, reviewed by Amit Kapila
2014-01-19 01:24:20 +01:00
pgstat_report_vacuum(Oid tableoid, bool shared,
PgStat_Counter livetuples, PgStat_Counter deadtuples)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
{
PgStat_MsgVacuum msg;
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET || !pgstat_track_counts)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
return;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_VACUUM);
msg.m_databaseid = shared ? InvalidOid : MyDatabaseId;
msg.m_tableoid = tableoid;
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
msg.m_autovacuum = IsAutoVacuumWorkerProcess();
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
msg.m_vacuumtime = GetCurrentTimestamp();
Fix VACUUM's reporting of dead-tuple counts to the stats collector. Historically, VACUUM has just reported its new_rel_tuples estimate (the same thing it puts into pg_class.reltuples) to the stats collector. That number counts both live and dead-but-not-yet-reclaimable tuples. This behavior may once have been right, but modern versions of the pgstats code track live and dead tuple counts separately, so putting the total into n_live_tuples and zero into n_dead_tuples is surely pretty bogus. Fix it to report live and dead tuple counts separately. This doesn't really do much for situations where updating transactions commit concurrently with a VACUUM scan (possibly causing double-counting or omission of the tuples they add or delete); but it's clearly an improvement over what we were doing before. Hari Babu, reviewed by Amit Kapila
2014-01-19 01:24:20 +01:00
msg.m_live_tuples = livetuples;
msg.m_dead_tuples = deadtuples;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
pgstat_send(&msg, sizeof(msg));
}
/* --------
* pgstat_report_analyze() -
*
* Tell the collector about the table we just analyzed.
* --------
*/
void
Fix VACUUM so that it always updates pg_class.reltuples/relpages. When we added the ability for vacuum to skip heap pages by consulting the visibility map, we made it just not update the reltuples/relpages statistics if it skipped any pages. But this could leave us with extremely out-of-date stats for a table that contains any unchanging areas, especially for TOAST tables which never get processed by ANALYZE. In particular this could result in autovacuum making poor decisions about when to process the table, as in recent report from Florian Helmberger. And in general it's a bad idea to not update the stats at all. Instead, use the previous values of reltuples/relpages as an estimate of the tuple density in unvisited pages. This approach results in a "moving average" estimate of reltuples, which should converge to the correct value over multiple VACUUM and ANALYZE cycles even when individual measurements aren't very good. This new method for updating reltuples is used by both VACUUM and ANALYZE, with the result that we no longer need the grotty interconnections that caused ANALYZE to not update the stats depending on what had happened in the parent VACUUM command. Also, fix the logic for skipping all-visible pages during VACUUM so that it looks ahead rather than behind to decide what to do, as per a suggestion from Greg Stark. This eliminates useless scanning of all-visible pages at the start of the relation or just after a not-all-visible page. In particular, the first few pages of the relation will not be invariably included in the scanned pages, which seems to help in not overweighting them in the reltuples estimate. Back-patch to 8.4, where the visibility map was introduced.
2011-05-30 23:05:26 +02:00
pgstat_report_analyze(Relation rel,
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
PgStat_Counter livetuples, PgStat_Counter deadtuples)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
{
PgStat_MsgAnalyze msg;
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET || !pgstat_track_counts)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
return;
Teach ANALYZE to distinguish dead and in-doubt tuples, which it formerly classed all as "dead"; also get it to count DEAD item pointers as dead rows, instead of ignoring them as before. Also improve matters so that tuples previously inserted or deleted by our own transaction are handled nicely: the stats collector's live-tuple and dead-tuple counts will end up correct after our transaction ends, regardless of whether we end in commit or abort. While there's more work that could be done to improve the counting of in-doubt tuples in both VACUUM and ANALYZE, this commit is enough to alleviate some known bad behaviors in 8.3; and the other stuff that's been discussed seems like research projects anyway. Pavan Deolasee and Tom Lane
2008-04-03 18:27:25 +02:00
/*
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* Unlike VACUUM, ANALYZE might be running inside a transaction that has
* already inserted and/or deleted rows in the target table. ANALYZE will
* have counted such rows as live or dead respectively. Because we will
* report our counts of such rows at transaction end, we should subtract
* off these counts from what we send to the collector now, else they'll
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* be double-counted after commit. (This approach also ensures that the
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* collector ends up with the right numbers if we abort instead of
* committing.)
Teach ANALYZE to distinguish dead and in-doubt tuples, which it formerly classed all as "dead"; also get it to count DEAD item pointers as dead rows, instead of ignoring them as before. Also improve matters so that tuples previously inserted or deleted by our own transaction are handled nicely: the stats collector's live-tuple and dead-tuple counts will end up correct after our transaction ends, regardless of whether we end in commit or abort. While there's more work that could be done to improve the counting of in-doubt tuples in both VACUUM and ANALYZE, this commit is enough to alleviate some known bad behaviors in 8.3; and the other stuff that's been discussed seems like research projects anyway. Pavan Deolasee and Tom Lane
2008-04-03 18:27:25 +02:00
*/
if (rel->pgstat_info != NULL)
{
PgStat_TableXactStatus *trans;
for (trans = rel->pgstat_info->trans; trans; trans = trans->upper)
{
livetuples -= trans->tuples_inserted - trans->tuples_deleted;
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
deadtuples -= trans->tuples_updated + trans->tuples_deleted;
Teach ANALYZE to distinguish dead and in-doubt tuples, which it formerly classed all as "dead"; also get it to count DEAD item pointers as dead rows, instead of ignoring them as before. Also improve matters so that tuples previously inserted or deleted by our own transaction are handled nicely: the stats collector's live-tuple and dead-tuple counts will end up correct after our transaction ends, regardless of whether we end in commit or abort. While there's more work that could be done to improve the counting of in-doubt tuples in both VACUUM and ANALYZE, this commit is enough to alleviate some known bad behaviors in 8.3; and the other stuff that's been discussed seems like research projects anyway. Pavan Deolasee and Tom Lane
2008-04-03 18:27:25 +02:00
}
/* count stuff inserted by already-aborted subxacts, too */
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
deadtuples -= rel->pgstat_info->t_counts.t_delta_dead_tuples;
Teach ANALYZE to distinguish dead and in-doubt tuples, which it formerly classed all as "dead"; also get it to count DEAD item pointers as dead rows, instead of ignoring them as before. Also improve matters so that tuples previously inserted or deleted by our own transaction are handled nicely: the stats collector's live-tuple and dead-tuple counts will end up correct after our transaction ends, regardless of whether we end in commit or abort. While there's more work that could be done to improve the counting of in-doubt tuples in both VACUUM and ANALYZE, this commit is enough to alleviate some known bad behaviors in 8.3; and the other stuff that's been discussed seems like research projects anyway. Pavan Deolasee and Tom Lane
2008-04-03 18:27:25 +02:00
/* Since ANALYZE's counts are estimates, we could have underflowed */
livetuples = Max(livetuples, 0);
deadtuples = Max(deadtuples, 0);
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_ANALYZE);
Teach ANALYZE to distinguish dead and in-doubt tuples, which it formerly classed all as "dead"; also get it to count DEAD item pointers as dead rows, instead of ignoring them as before. Also improve matters so that tuples previously inserted or deleted by our own transaction are handled nicely: the stats collector's live-tuple and dead-tuple counts will end up correct after our transaction ends, regardless of whether we end in commit or abort. While there's more work that could be done to improve the counting of in-doubt tuples in both VACUUM and ANALYZE, this commit is enough to alleviate some known bad behaviors in 8.3; and the other stuff that's been discussed seems like research projects anyway. Pavan Deolasee and Tom Lane
2008-04-03 18:27:25 +02:00
msg.m_databaseid = rel->rd_rel->relisshared ? InvalidOid : MyDatabaseId;
msg.m_tableoid = RelationGetRelid(rel);
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
msg.m_autovacuum = IsAutoVacuumWorkerProcess();
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
msg.m_analyzetime = GetCurrentTimestamp();
msg.m_live_tuples = livetuples;
msg.m_dead_tuples = deadtuples;
pgstat_send(&msg, sizeof(msg));
}
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
/* --------
* pgstat_report_recovery_conflict() -
*
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* Tell the collector about a Hot Standby recovery conflict.
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
* --------
*/
void
pgstat_report_recovery_conflict(int reason)
{
PgStat_MsgRecoveryConflict msg;
if (pgStatSock == PGINVALID_SOCKET || !pgstat_track_counts)
return;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_RECOVERYCONFLICT);
msg.m_databaseid = MyDatabaseId;
msg.m_reason = reason;
pgstat_send(&msg, sizeof(msg));
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Add deadlock counter to pg_stat_database Adds a counter that tracks number of deadlocks that occurred in each database to pg_stat_database. Magnus Hagander, reviewed by Jaime Casanova
2012-01-26 15:58:19 +01:00
/* --------
* pgstat_report_deadlock() -
*
* Tell the collector about a deadlock detected.
* --------
*/
void
pgstat_report_deadlock(void)
{
PgStat_MsgDeadlock msg;
if (pgStatSock == PGINVALID_SOCKET || !pgstat_track_counts)
return;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_DEADLOCK);
msg.m_databaseid = MyDatabaseId;
pgstat_send(&msg, sizeof(msg));
}
Track temporary file count and size in pg_stat_database Add counters for number and size of temporary files used for spill-to-disk queries for each database to the pg_stat_database view. Tomas Vondra, review by Magnus Hagander
2012-01-26 14:41:19 +01:00
/* --------
* pgstat_report_tempfile() -
*
* Tell the collector about a temporary file.
* --------
*/
void
pgstat_report_tempfile(size_t filesize)
{
PgStat_MsgTempFile msg;
if (pgStatSock == PGINVALID_SOCKET || !pgstat_track_counts)
return;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_TEMPFILE);
msg.m_databaseid = MyDatabaseId;
msg.m_filesize = filesize;
pgstat_send(&msg, sizeof(msg));
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
* pgstat_ping() -
*
* Send some junk data to the collector to increase traffic.
* ----------
*/
void
pgstat_ping(void)
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
PgStat_MsgDummy msg;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
return;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_DUMMY);
pgstat_send(&msg, sizeof(msg));
}
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
/* ----------
* pgstat_send_inquiry() -
*
* Notify collector that we need fresh data.
* ----------
*/
static void
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgstat_send_inquiry(TimestampTz clock_time, TimestampTz cutoff_time, Oid databaseid)
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
{
PgStat_MsgInquiry msg;
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_INQUIRY);
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
msg.clock_time = clock_time;
msg.cutoff_time = cutoff_time;
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
msg.databaseid = databaseid;
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
pgstat_send(&msg, sizeof(msg));
}
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/*
* Initialize function call usage data.
* Called by the executor before invoking a function.
*/
void
pgstat_init_function_usage(FunctionCallInfoData *fcinfo,
PgStat_FunctionCallUsage *fcu)
{
PgStat_BackendFunctionEntry *htabent;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
bool found;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
if (pgstat_track_functions <= fcinfo->flinfo->fn_stats)
{
/* stats not wanted */
fcu->fs = NULL;
return;
}
if (!pgStatFunctions)
{
/* First time through - initialize function stat table */
HASHCTL hash_ctl;
memset(&hash_ctl, 0, sizeof(hash_ctl));
hash_ctl.keysize = sizeof(Oid);
hash_ctl.entrysize = sizeof(PgStat_BackendFunctionEntry);
pgStatFunctions = hash_create("Function stat entries",
PGSTAT_FUNCTION_HASH_SIZE,
&hash_ctl,
Improve hash_create's API for selecting simple-binary-key hash functions. Previously, if you wanted anything besides C-string hash keys, you had to specify a custom hashing function to hash_create(). Nearly all such callers were specifying tag_hash or oid_hash; which is tedious, and rather error-prone, since a caller could easily miss the opportunity to optimize by using hash_uint32 when appropriate. Replace this with a design whereby callers using simple binary-data keys just specify HASH_BLOBS and don't need to mess with specific support functions. hash_create() itself will take care of optimizing when the key size is four bytes. This nets out saving a few hundred bytes of code space, and offers a measurable performance improvement in tidbitmap.c (which was not exploiting the opportunity to use hash_uint32 for its 4-byte keys). There might be some wins elsewhere too, I didn't analyze closely. In future we could look into offering a similar optimized hashing function for 8-byte keys. Under this design that could be done in a centralized and machine-independent fashion, whereas getting it right for keys of platform-dependent sizes would've been notationally painful before. For the moment, the old way still works fine, so as not to break source code compatibility for loadable modules. Eventually we might want to remove tag_hash and friends from the exported API altogether, since there's no real need for them to be explicitly referenced from outside dynahash.c. Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
HASH_ELEM | HASH_BLOBS);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
}
/* Get the stats entry for this function, create if necessary */
htabent = hash_search(pgStatFunctions, &fcinfo->flinfo->fn_oid,
HASH_ENTER, &found);
if (!found)
MemSet(&htabent->f_counts, 0, sizeof(PgStat_FunctionCounts));
fcu->fs = &htabent->f_counts;
/* save stats for this function, later used to compensate for recursion */
Converge all SQL-level statistics timing values to float8 milliseconds. This patch adjusts the core statistics views to match the decision already taken for pg_stat_statements, that values representing elapsed time should be represented as float8 and measured in milliseconds. By using float8, we are no longer tied to a specific maximum precision of timing data. (Internally, it's still microseconds, but we could now change that without needing changes at the SQL level.) The columns affected are pg_stat_bgwriter.checkpoint_write_time pg_stat_bgwriter.checkpoint_sync_time pg_stat_database.blk_read_time pg_stat_database.blk_write_time pg_stat_user_functions.total_time pg_stat_user_functions.self_time pg_stat_xact_user_functions.total_time pg_stat_xact_user_functions.self_time The first four of these are new in 9.2, so there is no compatibility issue from changing them. The others require a release note comment that they are now double precision (and can show a fractional part) rather than bigint as before; also their underlying statistics functions now match the column definitions, instead of returning bigint microseconds.
2012-04-30 20:02:47 +02:00
fcu->save_f_total_time = htabent->f_counts.f_total_time;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/* save current backend-wide total time */
fcu->save_total = total_func_time;
/* get clock time as of function start */
INSTR_TIME_SET_CURRENT(fcu->f_start);
}
Add stats functions and views to provide access to a transaction's own statistics counts. These numbers are being accumulated but haven't yet been transmitted to the collector (and won't be, until the transaction ends). For some purposes, though, it's handy to be able to look at them. Joel Jacobson, reviewed by Itagaki Takahiro
2010-08-08 18:27:06 +02:00
/*
* find_funcstat_entry - find any existing PgStat_BackendFunctionEntry entry
* for specified function
*
* If no entry, return NULL, don't create a new one
*/
PgStat_BackendFunctionEntry *
find_funcstat_entry(Oid func_id)
{
if (pgStatFunctions == NULL)
return NULL;
return (PgStat_BackendFunctionEntry *) hash_search(pgStatFunctions,
(void *) &func_id,
HASH_FIND, NULL);
}
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/*
* Calculate function call usage and update stat counters.
* Called by the executor after invoking a function.
*
* In the case of a set-returning function that runs in value-per-call mode,
* we will see multiple pgstat_init_function_usage/pgstat_end_function_usage
* calls for what the user considers a single call of the function. The
* finalize flag should be TRUE on the last call.
*/
void
pgstat_end_function_usage(PgStat_FunctionCallUsage *fcu, bool finalize)
{
PgStat_FunctionCounts *fs = fcu->fs;
instr_time f_total;
instr_time f_others;
instr_time f_self;
/* stats not wanted? */
if (fs == NULL)
return;
/* total elapsed time in this function call */
INSTR_TIME_SET_CURRENT(f_total);
INSTR_TIME_SUBTRACT(f_total, fcu->f_start);
/* self usage: elapsed minus anything already charged to other calls */
f_others = total_func_time;
INSTR_TIME_SUBTRACT(f_others, fcu->save_total);
f_self = f_total;
INSTR_TIME_SUBTRACT(f_self, f_others);
/* update backend-wide total time */
INSTR_TIME_ADD(total_func_time, f_self);
/*
Converge all SQL-level statistics timing values to float8 milliseconds. This patch adjusts the core statistics views to match the decision already taken for pg_stat_statements, that values representing elapsed time should be represented as float8 and measured in milliseconds. By using float8, we are no longer tied to a specific maximum precision of timing data. (Internally, it's still microseconds, but we could now change that without needing changes at the SQL level.) The columns affected are pg_stat_bgwriter.checkpoint_write_time pg_stat_bgwriter.checkpoint_sync_time pg_stat_database.blk_read_time pg_stat_database.blk_write_time pg_stat_user_functions.total_time pg_stat_user_functions.self_time pg_stat_xact_user_functions.total_time pg_stat_xact_user_functions.self_time The first four of these are new in 9.2, so there is no compatibility issue from changing them. The others require a release note comment that they are now double precision (and can show a fractional part) rather than bigint as before; also their underlying statistics functions now match the column definitions, instead of returning bigint microseconds.
2012-04-30 20:02:47 +02:00
* Compute the new f_total_time as the total elapsed time added to the
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* pre-call value of f_total_time. This is necessary to avoid
Converge all SQL-level statistics timing values to float8 milliseconds. This patch adjusts the core statistics views to match the decision already taken for pg_stat_statements, that values representing elapsed time should be represented as float8 and measured in milliseconds. By using float8, we are no longer tied to a specific maximum precision of timing data. (Internally, it's still microseconds, but we could now change that without needing changes at the SQL level.) The columns affected are pg_stat_bgwriter.checkpoint_write_time pg_stat_bgwriter.checkpoint_sync_time pg_stat_database.blk_read_time pg_stat_database.blk_write_time pg_stat_user_functions.total_time pg_stat_user_functions.self_time pg_stat_xact_user_functions.total_time pg_stat_xact_user_functions.self_time The first four of these are new in 9.2, so there is no compatibility issue from changing them. The others require a release note comment that they are now double precision (and can show a fractional part) rather than bigint as before; also their underlying statistics functions now match the column definitions, instead of returning bigint microseconds.
2012-04-30 20:02:47 +02:00
* double-counting any time taken by recursive calls of myself. (We do
* not need any similar kluge for self time, since that already excludes
* any recursive calls.)
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
*/
Converge all SQL-level statistics timing values to float8 milliseconds. This patch adjusts the core statistics views to match the decision already taken for pg_stat_statements, that values representing elapsed time should be represented as float8 and measured in milliseconds. By using float8, we are no longer tied to a specific maximum precision of timing data. (Internally, it's still microseconds, but we could now change that without needing changes at the SQL level.) The columns affected are pg_stat_bgwriter.checkpoint_write_time pg_stat_bgwriter.checkpoint_sync_time pg_stat_database.blk_read_time pg_stat_database.blk_write_time pg_stat_user_functions.total_time pg_stat_user_functions.self_time pg_stat_xact_user_functions.total_time pg_stat_xact_user_functions.self_time The first four of these are new in 9.2, so there is no compatibility issue from changing them. The others require a release note comment that they are now double precision (and can show a fractional part) rather than bigint as before; also their underlying statistics functions now match the column definitions, instead of returning bigint microseconds.
2012-04-30 20:02:47 +02:00
INSTR_TIME_ADD(f_total, fcu->save_f_total_time);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/* update counters in function stats table */
if (finalize)
fs->f_numcalls++;
Converge all SQL-level statistics timing values to float8 milliseconds. This patch adjusts the core statistics views to match the decision already taken for pg_stat_statements, that values representing elapsed time should be represented as float8 and measured in milliseconds. By using float8, we are no longer tied to a specific maximum precision of timing data. (Internally, it's still microseconds, but we could now change that without needing changes at the SQL level.) The columns affected are pg_stat_bgwriter.checkpoint_write_time pg_stat_bgwriter.checkpoint_sync_time pg_stat_database.blk_read_time pg_stat_database.blk_write_time pg_stat_user_functions.total_time pg_stat_user_functions.self_time pg_stat_xact_user_functions.total_time pg_stat_xact_user_functions.self_time The first four of these are new in 9.2, so there is no compatibility issue from changing them. The others require a release note comment that they are now double precision (and can show a fractional part) rather than bigint as before; also their underlying statistics functions now match the column definitions, instead of returning bigint microseconds.
2012-04-30 20:02:47 +02:00
fs->f_total_time = f_total;
INSTR_TIME_ADD(fs->f_self_time, f_self);
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
/* indicate that we have something to send */
have_function_stats = true;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
* pgstat_initstats() -
*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* Initialize a relcache entry to count access statistics.
* Called whenever a relation is opened.
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
*
* We assume that a relcache entry's pgstat_info field is zeroed by
* relcache.c when the relcache entry is made; thereafter it is long-lived
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* data. We can avoid repeated searches of the TabStatus arrays when the
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
* same relation is touched repeatedly within a transaction.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
void
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
pgstat_initstats(Relation rel)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Oid rel_id = rel->rd_id;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
char relkind = rel->rd_rel->relkind;
/* We only count stats for things that have storage */
if (!(relkind == RELKIND_RELATION ||
Add a materialized view relations. A materialized view has a rule just like a view and a heap and other physical properties like a table. The rule is only used to populate the table, references in queries refer to the materialized data. This is a minimal implementation, but should still be useful in many cases. Currently data is only populated "on demand" by the CREATE MATERIALIZED VIEW and REFRESH MATERIALIZED VIEW statements. It is expected that future releases will add incremental updates with various timings, and that a more refined concept of defining what is "fresh" data will be developed. At some point it may even be possible to have queries use a materialized in place of references to underlying tables, but that requires the other above-mentioned features to be working first. Much of the documentation work by Robert Haas. Review by Noah Misch, Thom Brown, Robert Haas, Marko Tiikkaja Security review by KaiGai Kohei, with a decision on how best to implement sepgsql still pending.
2013-03-04 01:23:31 +01:00
relkind == RELKIND_MATVIEW ||
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
relkind == RELKIND_INDEX ||
Fix an oversight in an 8.3-era patch: pgstat_initstats should allow stats to be collected for sequences. Report and fix by Akira Kurosawa
2009-10-03 00:49:50 +02:00
relkind == RELKIND_TOASTVALUE ||
relkind == RELKIND_SEQUENCE))
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
{
rel->pgstat_info = NULL;
return;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET || !pgstat_track_counts)
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/* We're not counting at all */
rel->pgstat_info = NULL;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
return;
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* If we already set up this relation in the current transaction, nothing
* to do.
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
*/
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
if (rel->pgstat_info != NULL &&
rel->pgstat_info->t_id == rel_id)
Adjust pgstat_initstats() to avoid repeated searches of the TabStat arrays when a relation is opened multiple times in the same transaction. This is particularly useful for system catalogs, which we may heap_open or index_open many times in a transaction, and it doesn't really cost anything extra even if the rel is touched but once. Motivated by study of an example from Greg Stark, in which pgstat_initstats() accounted for an unreasonably large fraction of the runtime.
2007-04-21 06:10:53 +02:00
return;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/* Else find or make the PgStat_TableStatus entry, and update link */
rel->pgstat_info = get_tabstat_entry(rel_id, rel->rd_rel->relisshared);
}
/*
* get_tabstat_entry - find or create a PgStat_TableStatus entry for rel
*/
static PgStat_TableStatus *
get_tabstat_entry(Oid rel_id, bool isshared)
{
PgStat_TableStatus *entry;
TabStatusArray *tsa;
TabStatusArray *prev_tsa;
int i;
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* Search the already-used tabstat slots for this relation.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
prev_tsa = NULL;
for (tsa = pgStatTabList; tsa != NULL; prev_tsa = tsa, tsa = tsa->tsa_next)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
for (i = 0; i < tsa->tsa_used; i++)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
entry = &tsa->tsa_entries[i];
if (entry->t_id == rel_id)
return entry;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
if (tsa->tsa_used < TABSTAT_QUANTUM)
{
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* It must not be present, but we found a free slot instead. Fine,
* let's use this one. We assume the entry was already zeroed,
* either at creation or after last use.
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
*/
entry = &tsa->tsa_entries[tsa->tsa_used++];
entry->t_id = rel_id;
entry->t_shared = isshared;
return entry;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
/*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* We ran out of tabstat slots, so allocate more. Be sure they're zeroed.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
tsa = (TabStatusArray *) MemoryContextAllocZero(TopMemoryContext,
sizeof(TabStatusArray));
if (prev_tsa)
prev_tsa->tsa_next = tsa;
else
pgStatTabList = tsa;
/*
* Use the first entry of the new TabStatusArray.
*/
entry = &tsa->tsa_entries[tsa->tsa_used++];
entry->t_id = rel_id;
entry->t_shared = isshared;
return entry;
}
Add stats functions and views to provide access to a transaction's own statistics counts. These numbers are being accumulated but haven't yet been transmitted to the collector (and won't be, until the transaction ends). For some purposes, though, it's handy to be able to look at them. Joel Jacobson, reviewed by Itagaki Takahiro
2010-08-08 18:27:06 +02:00
/*
* find_tabstat_entry - find any existing PgStat_TableStatus entry for rel
*
* If no entry, return NULL, don't create a new one
*/
PgStat_TableStatus *
find_tabstat_entry(Oid rel_id)
{
PgStat_TableStatus *entry;
TabStatusArray *tsa;
int i;
for (tsa = pgStatTabList; tsa != NULL; tsa = tsa->tsa_next)
{
for (i = 0; i < tsa->tsa_used; i++)
{
entry = &tsa->tsa_entries[i];
if (entry->t_id == rel_id)
return entry;
}
}
/* Not present */
return NULL;
}
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/*
* get_tabstat_stack_level - add a new (sub)transaction stack entry if needed
*/
static PgStat_SubXactStatus *
get_tabstat_stack_level(int nest_level)
{
PgStat_SubXactStatus *xact_state;
xact_state = pgStatXactStack;
if (xact_state == NULL || xact_state->nest_level != nest_level)
{
xact_state = (PgStat_SubXactStatus *)
MemoryContextAlloc(TopTransactionContext,
sizeof(PgStat_SubXactStatus));
xact_state->nest_level = nest_level;
xact_state->prev = pgStatXactStack;
xact_state->first = NULL;
pgStatXactStack = xact_state;
}
return xact_state;
}
/*
* add_tabstat_xact_level - add a new (sub)transaction state record
*/
static void
Re-run pgindent with updated list of typedefs. (Updated README should avoid this problem in the future.)
2007-11-15 23:25:18 +01:00
add_tabstat_xact_level(PgStat_TableStatus *pgstat_info, int nest_level)
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
{
PgStat_SubXactStatus *xact_state;
PgStat_TableXactStatus *trans;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* If this is the first rel to be modified at the current nest level, we
* first have to push a transaction stack entry.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
xact_state = get_tabstat_stack_level(nest_level);
/* Now make a per-table stack entry */
trans = (PgStat_TableXactStatus *)
MemoryContextAllocZero(TopTransactionContext,
sizeof(PgStat_TableXactStatus));
trans->nest_level = nest_level;
trans->upper = pgstat_info->trans;
trans->parent = pgstat_info;
trans->next = xact_state->first;
xact_state->first = trans;
pgstat_info->trans = trans;
}
/*
In COPY, insert tuples to the heap in batches. This greatly reduces the WAL volume, especially when the table is narrow. The overhead of locking the heap page is also reduced. Reduced WAL traffic also makes it scale a lot better, if you run multiple COPY processes at the same time.
2011-11-09 09:54:41 +01:00
* pgstat_count_heap_insert - count a tuple insertion of n tuples
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
*/
void
In COPY, insert tuples to the heap in batches. This greatly reduces the WAL volume, especially when the table is narrow. The overhead of locking the heap page is also reduced. Reduced WAL traffic also makes it scale a lot better, if you run multiple COPY processes at the same time.
2011-11-09 09:54:41 +01:00
pgstat_count_heap_insert(Relation rel, int n)
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
{
PgStat_TableStatus *pgstat_info = rel->pgstat_info;
Remove some unnecessary tests of pgstat_track_counts. We may as well make pgstat_count_heap_scan() and related macros just count whenever rel->pgstat_info isn't null. Testing pgstat_track_counts buys nothing at all in the normal case where that flag is ON; and when it's OFF, the pgstat_info link will be null, so it's still a useless test. This change is unlikely to buy any noticeable performance improvement, but a cycle shaved is a cycle earned; and my investigations earlier today convinced me that we're down to the point where individual instructions in the inner execution loops are starting to matter.
2010-10-12 20:44:25 +02:00
if (pgstat_info != NULL)
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
{
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/* We have to log the effect at the proper transactional level */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
int nest_level = GetCurrentTransactionNestLevel();
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
if (pgstat_info->trans == NULL ||
pgstat_info->trans->nest_level != nest_level)
add_tabstat_xact_level(pgstat_info, nest_level);
In COPY, insert tuples to the heap in batches. This greatly reduces the WAL volume, especially when the table is narrow. The overhead of locking the heap page is also reduced. Reduced WAL traffic also makes it scale a lot better, if you run multiple COPY processes at the same time.
2011-11-09 09:54:41 +01:00
pgstat_info->trans->tuples_inserted += n;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
}
}
/*
* pgstat_count_heap_update - count a tuple update
*/
void
HOT updates. When we update a tuple without changing any of its indexed columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
2007-09-20 19:56:33 +02:00
pgstat_count_heap_update(Relation rel, bool hot)
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
{
PgStat_TableStatus *pgstat_info = rel->pgstat_info;
Remove some unnecessary tests of pgstat_track_counts. We may as well make pgstat_count_heap_scan() and related macros just count whenever rel->pgstat_info isn't null. Testing pgstat_track_counts buys nothing at all in the normal case where that flag is ON; and when it's OFF, the pgstat_info link will be null, so it's still a useless test. This change is unlikely to buy any noticeable performance improvement, but a cycle shaved is a cycle earned; and my investigations earlier today convinced me that we're down to the point where individual instructions in the inner execution loops are starting to matter.
2010-10-12 20:44:25 +02:00
if (pgstat_info != NULL)
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
{
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/* We have to log the effect at the proper transactional level */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
int nest_level = GetCurrentTransactionNestLevel();
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
if (pgstat_info->trans == NULL ||
pgstat_info->trans->nest_level != nest_level)
add_tabstat_xact_level(pgstat_info, nest_level);
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
pgstat_info->trans->tuples_updated++;
/* t_tuples_hot_updated is nontransactional, so just advance it */
if (hot)
pgstat_info->t_counts.t_tuples_hot_updated++;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
}
}
/*
* pgstat_count_heap_delete - count a tuple deletion
*/
void
pgstat_count_heap_delete(Relation rel)
{
PgStat_TableStatus *pgstat_info = rel->pgstat_info;
Remove some unnecessary tests of pgstat_track_counts. We may as well make pgstat_count_heap_scan() and related macros just count whenever rel->pgstat_info isn't null. Testing pgstat_track_counts buys nothing at all in the normal case where that flag is ON; and when it's OFF, the pgstat_info link will be null, so it's still a useless test. This change is unlikely to buy any noticeable performance improvement, but a cycle shaved is a cycle earned; and my investigations earlier today convinced me that we're down to the point where individual instructions in the inner execution loops are starting to matter.
2010-10-12 20:44:25 +02:00
if (pgstat_info != NULL)
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
{
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/* We have to log the effect at the proper transactional level */
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
int nest_level = GetCurrentTransactionNestLevel();
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
if (pgstat_info->trans == NULL ||
pgstat_info->trans->nest_level != nest_level)
add_tabstat_xact_level(pgstat_info, nest_level);
pgstat_info->trans->tuples_deleted++;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
/*
* pgstat_truncate_save_counters
*
* Whenever a table is truncated, we save its i/u/d counters so that they can
* be cleared, and if the (sub)xact that executed the truncate later aborts,
* the counters can be restored to the saved (pre-truncate) values. Note we do
* this on the first truncate in any particular subxact level only.
*/
static void
pgstat_truncate_save_counters(PgStat_TableXactStatus *trans)
{
if (!trans->truncated)
{
trans->inserted_pre_trunc = trans->tuples_inserted;
trans->updated_pre_trunc = trans->tuples_updated;
trans->deleted_pre_trunc = trans->tuples_deleted;
trans->truncated = true;
}
}
/*
* pgstat_truncate_restore_counters - restore counters when a truncate aborts
*/
static void
pgstat_truncate_restore_counters(PgStat_TableXactStatus *trans)
{
if (trans->truncated)
{
trans->tuples_inserted = trans->inserted_pre_trunc;
trans->tuples_updated = trans->updated_pre_trunc;
trans->tuples_deleted = trans->deleted_pre_trunc;
}
}
/*
* pgstat_count_truncate - update tuple counters due to truncate
*/
void
pgstat_count_truncate(Relation rel)
{
PgStat_TableStatus *pgstat_info = rel->pgstat_info;
if (pgstat_info != NULL)
{
/* We have to log the effect at the proper transactional level */
int nest_level = GetCurrentTransactionNestLevel();
if (pgstat_info->trans == NULL ||
pgstat_info->trans->nest_level != nest_level)
add_tabstat_xact_level(pgstat_info, nest_level);
pgstat_truncate_save_counters(pgstat_info->trans);
pgstat_info->trans->tuples_inserted = 0;
pgstat_info->trans->tuples_updated = 0;
pgstat_info->trans->tuples_deleted = 0;
}
}
HOT updates. When we update a tuple without changing any of its indexed columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
2007-09-20 19:56:33 +02:00
/*
* pgstat_update_heap_dead_tuples - update dead-tuples count
*
* The semantics of this are that we are reporting the nontransactional
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
* recovery of "delta" dead tuples; so t_delta_dead_tuples decreases
HOT updates. When we update a tuple without changing any of its indexed columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
2007-09-20 19:56:33 +02:00
* rather than increasing, and the change goes straight into the per-table
* counter, not into transactional state.
*/
void
pgstat_update_heap_dead_tuples(Relation rel, int delta)
{
PgStat_TableStatus *pgstat_info = rel->pgstat_info;
Remove some unnecessary tests of pgstat_track_counts. We may as well make pgstat_count_heap_scan() and related macros just count whenever rel->pgstat_info isn't null. Testing pgstat_track_counts buys nothing at all in the normal case where that flag is ON; and when it's OFF, the pgstat_info link will be null, so it's still a useless test. This change is unlikely to buy any noticeable performance improvement, but a cycle shaved is a cycle earned; and my investigations earlier today convinced me that we're down to the point where individual instructions in the inner execution loops are starting to matter.
2010-10-12 20:44:25 +02:00
if (pgstat_info != NULL)
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
pgstat_info->t_counts.t_delta_dead_tuples -= delta;
HOT updates. When we update a tuple without changing any of its indexed columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
2007-09-20 19:56:33 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* AtEOXact_PgStat
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* Called from access/transam/xact.c at top-level transaction commit/abort.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
void
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
AtEOXact_PgStat(bool isCommit)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
PgStat_SubXactStatus *xact_state;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* Count transaction commit or abort. (We use counters, not just bools,
* in case the reporting message isn't sent right away.)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
if (isCommit)
pgStatXactCommit++;
else
pgStatXactRollback++;
Use AllocateFile(), FreeFile() and palloc() rather than fopen(), fclose() and malloc() in pgstat.c, respectively. This simplifies error recovery, as well as being more consistent with the rest of the backend.
2004-10-28 03:38:41 +02:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/*
* Transfer transactional insert/update counts into the base tabstat
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* entries. We don't bother to free any of the transactional state, since
* it's all in TopTransactionContext and will go away anyway.
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
*/
xact_state = pgStatXactStack;
if (xact_state != NULL)
Avoid unnecessary work when stats collection is disabled. Tighten search loop in pgstat_initstats. Per report from Gavin Sherry.
2003-08-12 18:21:18 +02:00
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
PgStat_TableXactStatus *trans;
Assert(xact_state->nest_level == 1);
Assert(xact_state->prev == NULL);
for (trans = xact_state->first; trans != NULL; trans = trans->next)
{
PgStat_TableStatus *tabstat;
Assert(trans->nest_level == 1);
Assert(trans->upper == NULL);
tabstat = trans->parent;
Assert(tabstat->trans == trans);
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
/* restore pre-truncate stats (if any) in case of aborted xact */
if (!isCommit)
pgstat_truncate_restore_counters(trans);
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/* count attempted actions regardless of commit/abort */
tabstat->t_counts.t_tuples_inserted += trans->tuples_inserted;
tabstat->t_counts.t_tuples_updated += trans->tuples_updated;
tabstat->t_counts.t_tuples_deleted += trans->tuples_deleted;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
if (isCommit)
{
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
tabstat->t_counts.t_truncated = trans->truncated;
if (trans->truncated)
{
/* forget live/dead stats seen by backend thus far */
tabstat->t_counts.t_delta_live_tuples = 0;
tabstat->t_counts.t_delta_dead_tuples = 0;
}
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/* insert adds a live tuple, delete removes one */
tabstat->t_counts.t_delta_live_tuples +=
Ooops, I was too busy worrying about getting the transactional infrastructure right to think carefully about how insert and delete counts map to n_live_tuples. Of course a deletion should reduce n_live_tuples.
2007-05-27 19:28:36 +02:00
trans->tuples_inserted - trans->tuples_deleted;
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/* update and delete each create a dead tuple */
tabstat->t_counts.t_delta_dead_tuples +=
trans->tuples_updated + trans->tuples_deleted;
/* insert, update, delete each count as one change event */
tabstat->t_counts.t_changed_tuples +=
trans->tuples_inserted + trans->tuples_updated +
trans->tuples_deleted;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
}
else
{
/* inserted tuples are dead, deleted tuples are unaffected */
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
tabstat->t_counts.t_delta_dead_tuples +=
trans->tuples_inserted + trans->tuples_updated;
/* an aborted xact generates no changed_tuple events */
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
}
tabstat->trans = NULL;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
pgStatXactStack = NULL;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/* Make sure any stats snapshot is thrown away */
pgstat_clear_snapshot();
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* AtEOSubXact_PgStat
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* Called from access/transam/xact.c at subtransaction commit/abort.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
void
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
AtEOSubXact_PgStat(bool isCommit, int nestDepth)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
PgStat_SubXactStatus *xact_state;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* Transfer transactional insert/update counts into the next higher
* subtransaction state.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
xact_state = pgStatXactStack;
if (xact_state != NULL &&
xact_state->nest_level >= nestDepth)
{
PgStat_TableXactStatus *trans;
PgStat_TableXactStatus *next_trans;
/* delink xact_state from stack immediately to simplify reuse case */
pgStatXactStack = xact_state->prev;
for (trans = xact_state->first; trans != NULL; trans = next_trans)
{
PgStat_TableStatus *tabstat;
next_trans = trans->next;
Assert(trans->nest_level == nestDepth);
tabstat = trans->parent;
Assert(tabstat->trans == trans);
if (isCommit)
{
if (trans->upper && trans->upper->nest_level == nestDepth - 1)
{
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
if (trans->truncated)
{
/* propagate the truncate status one level up */
pgstat_truncate_save_counters(trans->upper);
/* replace upper xact stats with ours */
trans->upper->tuples_inserted = trans->tuples_inserted;
trans->upper->tuples_updated = trans->tuples_updated;
trans->upper->tuples_deleted = trans->tuples_deleted;
}
else
{
trans->upper->tuples_inserted += trans->tuples_inserted;
trans->upper->tuples_updated += trans->tuples_updated;
trans->upper->tuples_deleted += trans->tuples_deleted;
}
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
tabstat->trans = trans->upper;
pfree(trans);
}
else
{
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* When there isn't an immediate parent state, we can just
* reuse the record instead of going through a
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* palloc/pfree pushup (this works since it's all in
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* TopTransactionContext anyway). We have to re-link it
* into the parent level, though, and that might mean
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* pushing a new entry into the pgStatXactStack.
*/
PgStat_SubXactStatus *upper_xact_state;
upper_xact_state = get_tabstat_stack_level(nestDepth - 1);
trans->next = upper_xact_state->first;
upper_xact_state->first = trans;
trans->nest_level = nestDepth - 1;
}
}
else
{
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* On abort, update top-level tabstat counts, then forget the
* subtransaction
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
*/
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
/* first restore values obliterated by truncate */
pgstat_truncate_restore_counters(trans);
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/* count attempted actions regardless of commit/abort */
tabstat->t_counts.t_tuples_inserted += trans->tuples_inserted;
tabstat->t_counts.t_tuples_updated += trans->tuples_updated;
tabstat->t_counts.t_tuples_deleted += trans->tuples_deleted;
/* inserted tuples are dead, deleted tuples are unaffected */
tabstat->t_counts.t_delta_dead_tuples +=
trans->tuples_inserted + trans->tuples_updated;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
tabstat->trans = trans->upper;
pfree(trans);
}
}
pfree(xact_state);
}
}
/*
* AtPrepare_PgStat
* Save the transactional stats state at 2PC transaction prepare.
*
* In this phase we just generate 2PC records for all the pending
* transaction-dependent stats work.
*/
void
AtPrepare_PgStat(void)
{
PgStat_SubXactStatus *xact_state;
Use AllocateFile(), FreeFile() and palloc() rather than fopen(), fclose() and malloc() in pgstat.c, respectively. This simplifies error recovery, as well as being more consistent with the rest of the backend.
2004-10-28 03:38:41 +02:00
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
xact_state = pgStatXactStack;
if (xact_state != NULL)
Avoid unnecessary work when stats collection is disabled. Tighten search loop in pgstat_initstats. Per report from Gavin Sherry.
2003-08-12 18:21:18 +02:00
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
PgStat_TableXactStatus *trans;
Assert(xact_state->nest_level == 1);
Assert(xact_state->prev == NULL);
for (trans = xact_state->first; trans != NULL; trans = trans->next)
{
PgStat_TableStatus *tabstat;
TwoPhasePgStatRecord record;
Assert(trans->nest_level == 1);
Assert(trans->upper == NULL);
tabstat = trans->parent;
Assert(tabstat->trans == trans);
record.tuples_inserted = trans->tuples_inserted;
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
record.tuples_updated = trans->tuples_updated;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
record.tuples_deleted = trans->tuples_deleted;
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
record.inserted_pre_trunc = trans->inserted_pre_trunc;
record.updated_pre_trunc = trans->updated_pre_trunc;
record.deleted_pre_trunc = trans->deleted_pre_trunc;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
record.t_id = tabstat->t_id;
record.t_shared = tabstat->t_shared;
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
record.t_truncated = trans->truncated;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
RegisterTwoPhaseRecord(TWOPHASE_RM_PGSTAT_ID, 0,
&record, sizeof(TwoPhasePgStatRecord));
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
}
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/*
* PostPrepare_PgStat
* Clean up after successful PREPARE.
*
* All we need do here is unlink the transaction stats state from the
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* nontransactional state. The nontransactional action counts will be
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* reported to the stats collector immediately, while the effects on live
* and dead tuple counts are preserved in the 2PC state file.
*
* Note: AtEOXact_PgStat is not called during PREPARE.
*/
void
PostPrepare_PgStat(void)
{
PgStat_SubXactStatus *xact_state;
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* We don't bother to free any of the transactional state, since it's all
* in TopTransactionContext and will go away anyway.
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
*/
xact_state = pgStatXactStack;
if (xact_state != NULL)
{
PgStat_TableXactStatus *trans;
for (trans = xact_state->first; trans != NULL; trans = trans->next)
{
PgStat_TableStatus *tabstat;
tabstat = trans->parent;
tabstat->trans = NULL;
}
}
pgStatXactStack = NULL;
/* Make sure any stats snapshot is thrown away */
pgstat_clear_snapshot();
}
/*
* 2PC processing routine for COMMIT PREPARED case.
*
* Load the saved counts into our local pgstats state.
*/
void
pgstat_twophase_postcommit(TransactionId xid, uint16 info,
void *recdata, uint32 len)
{
TwoPhasePgStatRecord *rec = (TwoPhasePgStatRecord *) recdata;
PgStat_TableStatus *pgstat_info;
/* Find or create a tabstat entry for the rel */
pgstat_info = get_tabstat_entry(rec->t_id, rec->t_shared);
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/* Same math as in AtEOXact_PgStat, commit case */
pgstat_info->t_counts.t_tuples_inserted += rec->tuples_inserted;
pgstat_info->t_counts.t_tuples_updated += rec->tuples_updated;
pgstat_info->t_counts.t_tuples_deleted += rec->tuples_deleted;
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
pgstat_info->t_counts.t_truncated = rec->t_truncated;
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
pgstat_info->t_counts.t_delta_live_tuples +=
Ooops, I was too busy worrying about getting the transactional infrastructure right to think carefully about how insert and delete counts map to n_live_tuples. Of course a deletion should reduce n_live_tuples.
2007-05-27 19:28:36 +02:00
rec->tuples_inserted - rec->tuples_deleted;
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
pgstat_info->t_counts.t_delta_dead_tuples +=
rec->tuples_updated + rec->tuples_deleted;
pgstat_info->t_counts.t_changed_tuples +=
rec->tuples_inserted + rec->tuples_updated +
rec->tuples_deleted;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
}
/*
* 2PC processing routine for ROLLBACK PREPARED case.
*
* Load the saved counts into our local pgstats state, but treat them
* as aborted.
*/
void
pgstat_twophase_postabort(TransactionId xid, uint16 info,
void *recdata, uint32 len)
{
TwoPhasePgStatRecord *rec = (TwoPhasePgStatRecord *) recdata;
PgStat_TableStatus *pgstat_info;
/* Find or create a tabstat entry for the rel */
pgstat_info = get_tabstat_entry(rec->t_id, rec->t_shared);
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/* Same math as in AtEOXact_PgStat, abort case */
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
if (rec->t_truncated)
{
rec->tuples_inserted = rec->inserted_pre_trunc;
rec->tuples_updated = rec->updated_pre_trunc;
rec->tuples_deleted = rec->deleted_pre_trunc;
}
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
pgstat_info->t_counts.t_tuples_inserted += rec->tuples_inserted;
pgstat_info->t_counts.t_tuples_updated += rec->tuples_updated;
pgstat_info->t_counts.t_tuples_deleted += rec->tuples_deleted;
pgstat_info->t_counts.t_delta_dead_tuples +=
rec->tuples_inserted + rec->tuples_updated;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
* pgstat_fetch_stat_dbentry() -
*
* Support function for the SQL-callable pgstat* functions. Returns
* the collected statistics for one database or NULL. NULL doesn't mean
* that the database doesn't exist, it is just not yet known by the
* collector, so the caller is better off to report ZERO instead.
* ----------
*/
PgStat_StatDBEntry *
pgstat_fetch_stat_dbentry(Oid dbid)
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If not done for this transaction, read the statistics collector stats
* file into some hash tables.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
backend_read_statsfile();
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
* Lookup the requested database; return NULL if not found
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
return (PgStat_StatDBEntry *) hash_search(pgStatDBHash,
(void *) &dbid,
HASH_FIND, NULL);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
/* ----------
* pgstat_fetch_stat_tabentry() -
*
* Support function for the SQL-callable pgstat* functions. Returns
* the collected statistics for one table or NULL. NULL doesn't mean
* that the table doesn't exist, it is just not yet known by the
* collector, so the caller is better off to report ZERO instead.
* ----------
*/
PgStat_StatTabEntry *
pgstat_fetch_stat_tabentry(Oid relid)
{
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
Oid dbid;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
PgStat_StatDBEntry *dbentry;
PgStat_StatTabEntry *tabentry;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If not done for this transaction, read the statistics collector stats
* file into some hash tables.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
backend_read_statsfile();
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
* Lookup our database, then look in its table hash table.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
dbid = MyDatabaseId;
Another round of cleanups for dynahash.c (maybe it's finally clean of portability issues). Caller-visible data structures are now allocated on MAXALIGN boundaries, allowing safe use of datatypes wider than 'long'. Rejigger hash_create API so that caller specifies size of key and total size of entry, not size of key and size of rest of entry. This simplifies life considerably since each number is just a sizeof(), and padding issues etc. are taken care of automatically.
2001-10-01 07:36:17 +02:00
dbentry = (PgStat_StatDBEntry *) hash_search(pgStatDBHash,
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
(void *) &dbid,
Further cleanup of dynahash.c API, in pursuit of portability and readability. Bizarre '(long *) TRUE' return convention is gone, in favor of just raising an error internally in dynahash.c when we detect hashtable corruption. HashTableWalk is gone, in favor of using hash_seq_search directly, since it had no hope of working with non-LONGALIGNable datatypes. Simplify some other code that was made undesirably grotty by promixity to HashTableWalk.
2001-10-05 19:28:13 +02:00
HASH_FIND, NULL);
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
if (dbentry != NULL && dbentry->tables != NULL)
{
tabentry = (PgStat_StatTabEntry *) hash_search(dbentry->tables,
(void *) &relid,
HASH_FIND, NULL);
if (tabentry)
return tabentry;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
* If we didn't find it, maybe it's a shared table.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
dbid = InvalidOid;
dbentry = (PgStat_StatDBEntry *) hash_search(pgStatDBHash,
(void *) &dbid,
HASH_FIND, NULL);
if (dbentry != NULL && dbentry->tables != NULL)
{
tabentry = (PgStat_StatTabEntry *) hash_search(dbentry->tables,
(void *) &relid,
HASH_FIND, NULL);
if (tabentry)
return tabentry;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
return NULL;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/* ----------
* pgstat_fetch_stat_funcentry() -
*
* Support function for the SQL-callable pgstat* functions. Returns
* the collected statistics for one function or NULL.
* ----------
*/
PgStat_StatFuncEntry *
pgstat_fetch_stat_funcentry(Oid func_id)
{
PgStat_StatDBEntry *dbentry;
PgStat_StatFuncEntry *funcentry = NULL;
/* load the stats file if needed */
backend_read_statsfile();
/* Lookup our database, then find the requested function. */
dbentry = pgstat_fetch_stat_dbentry(MyDatabaseId);
if (dbentry != NULL && dbentry->functions != NULL)
{
funcentry = (PgStat_StatFuncEntry *) hash_search(dbentry->functions,
(void *) &func_id,
HASH_FIND, NULL);
}
return funcentry;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
* pgstat_fetch_stat_beentry() -
*
* Support function for the SQL-callable pgstat* functions. Returns
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
* our local copy of the current-activity entry for one backend.
*
* NB: caller is responsible for a check if the user is permitted to see
* this info (especially the querystring).
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
PgBackendStatus *
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgstat_fetch_stat_beentry(int beid)
{
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
pgstat_read_current_status();
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
if (beid < 1 || beid > localNumBackends)
return NULL;
return &localBackendStatusTable[beid - 1].backendStatus;
}
/* ----------
* pgstat_fetch_stat_local_beentry() -
*
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* Like pgstat_fetch_stat_beentry() but with locally computed addtions (like
* xid and xmin values of the backend)
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
*
* NB: caller is responsible for a check if the user is permitted to see
* this info (especially the querystring).
* ----------
*/
LocalPgBackendStatus *
pgstat_fetch_stat_local_beentry(int beid)
{
pgstat_read_current_status();
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
if (beid < 1 || beid > localNumBackends)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
return NULL;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
return &localBackendStatusTable[beid - 1];
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
/* ----------
* pgstat_fetch_stat_numbackends() -
*
* Support function for the SQL-callable pgstat* functions. Returns
* the maximum current backend id.
* ----------
*/
int
pgstat_fetch_stat_numbackends(void)
{
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
pgstat_read_current_status();
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
return localNumBackends;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
/*
* ---------
* pgstat_fetch_stat_archiver() -
*
* Support function for the SQL-callable pgstat* functions. Returns
* a pointer to the archiver statistics struct.
* ---------
*/
PgStat_ArchiverStats *
pgstat_fetch_stat_archiver(void)
{
backend_read_statsfile();
return &archiverStats;
}
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
/*
* ---------
* pgstat_fetch_global() -
*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* Support function for the SQL-callable pgstat* functions. Returns
* a pointer to the global statistics struct.
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
* ---------
*/
PgStat_GlobalStats *
pgstat_fetch_global(void)
{
backend_read_statsfile();
return &globalStats;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ------------------------------------------------------------
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
* Functions for management of the shared-memory PgBackendStatus array
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ------------------------------------------------------------
*/
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
static PgBackendStatus *BackendStatusArray = NULL;
static PgBackendStatus *MyBEEntry = NULL;
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
static char *BackendAppnameBuffer = NULL;
Further code review for pg_stat_ssl patch. Fix additional bogosity in commit 9029f4b37406b21a. Include the BackendSslStatusBuffer in the BackendStatusShmemSize calculation, avoid ugly and error-prone casts to char* and back, put related code stanzas into a consistent order (and fix a couple of previous instances of that sin). All cosmetic except for the size oversight.
2015-07-27 22:29:14 +02:00
static char *BackendClientHostnameBuffer = NULL;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
static char *BackendActivityBuffer = NULL;
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
static Size BackendActivityBufferSize = 0;
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
#ifdef USE_SSL
static PgBackendSSLStatus *BackendSslStatusBuffer = NULL;
#endif
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/*
* Report shared-memory space needed by CreateSharedBackendStatus.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Size
BackendStatusShmemSize(void)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Size size;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Further code review for pg_stat_ssl patch. Fix additional bogosity in commit 9029f4b37406b21a. Include the BackendSslStatusBuffer in the BackendStatusShmemSize calculation, avoid ugly and error-prone casts to char* and back, put related code stanzas into a consistent order (and fix a couple of previous instances of that sin). All cosmetic except for the size oversight.
2015-07-27 22:29:14 +02:00
/* BackendStatusArray: */
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
size = mul_size(sizeof(PgBackendStatus), MaxBackends);
Further code review for pg_stat_ssl patch. Fix additional bogosity in commit 9029f4b37406b21a. Include the BackendSslStatusBuffer in the BackendStatusShmemSize calculation, avoid ugly and error-prone casts to char* and back, put related code stanzas into a consistent order (and fix a couple of previous instances of that sin). All cosmetic except for the size oversight.
2015-07-27 22:29:14 +02:00
/* BackendAppnameBuffer: */
size = add_size(size,
mul_size(NAMEDATALEN, MaxBackends));
/* BackendClientHostnameBuffer: */
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
size = add_size(size,
mul_size(NAMEDATALEN, MaxBackends));
Further code review for pg_stat_ssl patch. Fix additional bogosity in commit 9029f4b37406b21a. Include the BackendSslStatusBuffer in the BackendStatusShmemSize calculation, avoid ugly and error-prone casts to char* and back, put related code stanzas into a consistent order (and fix a couple of previous instances of that sin). All cosmetic except for the size oversight.
2015-07-27 22:29:14 +02:00
/* BackendActivityBuffer: */
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
size = add_size(size,
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
mul_size(pgstat_track_activity_query_size, MaxBackends));
Further code review for pg_stat_ssl patch. Fix additional bogosity in commit 9029f4b37406b21a. Include the BackendSslStatusBuffer in the BackendStatusShmemSize calculation, avoid ugly and error-prone casts to char* and back, put related code stanzas into a consistent order (and fix a couple of previous instances of that sin). All cosmetic except for the size oversight.
2015-07-27 22:29:14 +02:00
#ifdef USE_SSL
/* BackendSslStatusBuffer: */
Add client_hostname field to pg_stat_activity. Peter Eisentraut, reviewed by Steve Singer, Alvaro Herrera, and me.
2011-02-17 22:03:28 +01:00
size = add_size(size,
Further code review for pg_stat_ssl patch. Fix additional bogosity in commit 9029f4b37406b21a. Include the BackendSslStatusBuffer in the BackendStatusShmemSize calculation, avoid ugly and error-prone casts to char* and back, put related code stanzas into a consistent order (and fix a couple of previous instances of that sin). All cosmetic except for the size oversight.
2015-07-27 22:29:14 +02:00
mul_size(sizeof(PgBackendSSLStatus), MaxBackends));
#endif
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
return size;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/*
Add client_hostname field to pg_stat_activity. Peter Eisentraut, reviewed by Steve Singer, Alvaro Herrera, and me.
2011-02-17 22:03:28 +01:00
* Initialize the shared status array and several string buffers
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
* during postmaster startup.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
void
CreateSharedBackendStatus(void)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
Size size;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
bool found;
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
int i;
char *buffer;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/* Create or attach to the shared array */
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
size = mul_size(sizeof(PgBackendStatus), MaxBackends);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
BackendStatusArray = (PgBackendStatus *)
ShmemInitStruct("Backend Status Array", size, &found);
if (!found)
{
/*
* We're the first - initialize.
*/
MemSet(BackendStatusArray, 0, size);
}
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
/* Create or attach to the shared appname buffer */
size = mul_size(NAMEDATALEN, MaxBackends);
BackendAppnameBuffer = (char *)
ShmemInitStruct("Backend Application Name Buffer", size, &found);
if (!found)
{
MemSet(BackendAppnameBuffer, 0, size);
/* Initialize st_appname pointers. */
buffer = BackendAppnameBuffer;
for (i = 0; i < MaxBackends; i++)
{
BackendStatusArray[i].st_appname = buffer;
buffer += NAMEDATALEN;
}
}
Add client_hostname field to pg_stat_activity. Peter Eisentraut, reviewed by Steve Singer, Alvaro Herrera, and me.
2011-02-17 22:03:28 +01:00
/* Create or attach to the shared client hostname buffer */
size = mul_size(NAMEDATALEN, MaxBackends);
BackendClientHostnameBuffer = (char *)
ShmemInitStruct("Backend Client Host Name Buffer", size, &found);
if (!found)
{
MemSet(BackendClientHostnameBuffer, 0, size);
/* Initialize st_clienthostname pointers. */
buffer = BackendClientHostnameBuffer;
for (i = 0; i < MaxBackends; i++)
{
BackendStatusArray[i].st_clienthostname = buffer;
buffer += NAMEDATALEN;
}
}
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
/* Create or attach to the shared activity buffer */
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
BackendActivityBufferSize = mul_size(pgstat_track_activity_query_size,
MaxBackends);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
BackendActivityBuffer = (char *)
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
ShmemInitStruct("Backend Activity Buffer",
BackendActivityBufferSize,
&found);
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
if (!found)
{
MemSet(BackendActivityBuffer, 0, size);
/* Initialize st_activity pointers. */
buffer = BackendActivityBuffer;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
for (i = 0; i < MaxBackends; i++)
{
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
BackendStatusArray[i].st_activity = buffer;
buffer += pgstat_track_activity_query_size;
}
}
Further code review for pg_stat_ssl patch. Fix additional bogosity in commit 9029f4b37406b21a. Include the BackendSslStatusBuffer in the BackendStatusShmemSize calculation, avoid ugly and error-prone casts to char* and back, put related code stanzas into a consistent order (and fix a couple of previous instances of that sin). All cosmetic except for the size oversight.
2015-07-27 22:29:14 +02:00
#ifdef USE_SSL
/* Create or attach to the shared SSL status buffer */
size = mul_size(sizeof(PgBackendSSLStatus), MaxBackends);
BackendSslStatusBuffer = (PgBackendSSLStatus *)
ShmemInitStruct("Backend SSL Status Buffer", size, &found);
if (!found)
{
PgBackendSSLStatus *ptr;
MemSet(BackendSslStatusBuffer, 0, size);
/* Initialize st_sslstatus pointers. */
ptr = BackendSslStatusBuffer;
for (i = 0; i < MaxBackends; i++)
{
BackendStatusArray[i].st_sslstatus = ptr;
ptr++;
}
}
#endif
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
}
pgstat's on-proc-exit hook has to execute after the last transaction commit or abort within a backend; rearrange InitPostgres processing to make it so. Revealed by just-added Asserts along with ECPG regression tests (hm, I wonder why the core regression tests didn't expose it?). This possibly is another reason for missing stats updates ...
2007-05-27 07:37:50 +02:00
/* ----------
* pgstat_initialize() -
*
* Initialize pgstats state, and set up our on-proc-exit hook.
* Called from InitPostgres. MyBackendId must be set,
* but we must not have started any transaction yet (since the
* exit hook must run after the last transaction exit).
Allow backends to start up without use of the flat-file copy of pg_database. To make this work in the base case, pg_database now has a nailed-in-cache relation descriptor that is initialized using hardwired knowledge in relcache.c. This means pg_database is added to the set of relations that need to have a Schema_pg_xxx macro maintained in pg_attribute.h. When this path is taken, we'll have to do a seqscan of pg_database to find the row we need. In the normal case, we are able to do an indexscan to find the database's row by name. This is made possible by storing a global relcache init file that describes only the shared catalogs and their indexes (and therefore is usable by all backends in any database). A new backend loads this cache file, finds its database OID after an indexscan on pg_database, and then loads the local relcache init file for that database. This change should effectively eliminate number of databases as a factor in backend startup time, even with large numbers of databases. However, the real reason for doing it is as a first step towards getting rid of the flat files altogether. There are still several other sub-projects to be tackled before that can happen.
2009-08-12 22:53:31 +02:00
* NOTE: MyDatabaseId isn't set yet; so the shutdown hook has to be careful.
pgstat's on-proc-exit hook has to execute after the last transaction commit or abort within a backend; rearrange InitPostgres processing to make it so. Revealed by just-added Asserts along with ECPG regression tests (hm, I wonder why the core regression tests didn't expose it?). This possibly is another reason for missing stats updates ...
2007-05-27 07:37:50 +02:00
* ----------
*/
void
pgstat_initialize(void)
{
/* Initialize MyBEEntry */
Assert(MyBackendId >= 1 && MyBackendId <= MaxBackends);
MyBEEntry = &BackendStatusArray[MyBackendId - 1];
/* Set up a process-exit hook to clean up */
on_shmem_exit(pgstat_beshutdown_hook, 0);
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/* ----------
* pgstat_bestart() -
*
pgstat's on-proc-exit hook has to execute after the last transaction commit or abort within a backend; rearrange InitPostgres processing to make it so. Revealed by just-added Asserts along with ECPG regression tests (hm, I wonder why the core regression tests didn't expose it?). This possibly is another reason for missing stats updates ...
2007-05-27 07:37:50 +02:00
* Initialize this backend's entry in the PgBackendStatus array.
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
* Called from InitPostgres.
* MyDatabaseId, session userid, and application_name must be set
pgstat's on-proc-exit hook has to execute after the last transaction commit or abort within a backend; rearrange InitPostgres processing to make it so. Revealed by just-added Asserts along with ECPG regression tests (hm, I wonder why the core regression tests didn't expose it?). This possibly is another reason for missing stats updates ...
2007-05-27 07:37:50 +02:00
* (hence, this cannot be combined with pgstat_initialize).
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
* ----------
*/
void
pgstat_bestart(void)
{
TimestampTz proc_start_timestamp;
Oid userid;
SockAddr clientaddr;
pgstat's on-proc-exit hook has to execute after the last transaction commit or abort within a backend; rearrange InitPostgres processing to make it so. Revealed by just-added Asserts along with ECPG regression tests (hm, I wonder why the core regression tests didn't expose it?). This possibly is another reason for missing stats updates ...
2007-05-27 07:37:50 +02:00
volatile PgBackendStatus *beentry;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* To minimize the time spent modifying the PgBackendStatus entry, fetch
* all the needed data first.
Remove redundant gettimeofday() calls to the extent practical without changing semantics too much. statement_timestamp is now set immediately upon receipt of a client command message, and the various places that used to do their own gettimeofday() calls to mark command startup are referenced to that instead. I have also made stats_command_string use that same value for pg_stat_activity.query_start for both the command itself and its eventual replacement by <IDLE> or <idle in transaction>. There was some debate about that, but no argument that seemed convincing enough to justify an extra gettimeofday() call.
2006-06-21 00:52:00 +02:00
*
* If we have a MyProcPort, use its session start time (for consistency,
* and to save a kernel call).
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
*/
Remove redundant gettimeofday() calls to the extent practical without changing semantics too much. statement_timestamp is now set immediately upon receipt of a client command message, and the various places that used to do their own gettimeofday() calls to mark command startup are referenced to that instead. I have also made stats_command_string use that same value for pg_stat_activity.query_start for both the command itself and its eventual replacement by <IDLE> or <idle in transaction>. There was some debate about that, but no argument that seemed convincing enough to justify an extra gettimeofday() call.
2006-06-21 00:52:00 +02:00
if (MyProcPort)
proc_start_timestamp = MyProcPort->SessionStartTime;
else
proc_start_timestamp = GetCurrentTimestamp();
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
userid = GetSessionUserId();
/*
* We may not have a MyProcPort (eg, if this is the autovacuum process).
* If so, use all-zeroes client address, which is dealt with specially in
* pg_stat_get_backend_client_addr and pg_stat_get_backend_client_port.
*/
if (MyProcPort)
memcpy(&clientaddr, &MyProcPort->raddr, sizeof(clientaddr));
else
MemSet(&clientaddr, 0, sizeof(clientaddr));
/*
* Initialize my status entry, following the protocol of bumping
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* st_changecount before and after; and make sure it's even afterwards. We
* use a volatile pointer here to ensure the compiler doesn't try to get
* cute.
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
*/
beentry = MyBEEntry;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
do
{
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_before(beentry);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
} while ((beentry->st_changecount & 1) == 0);
beentry->st_procpid = MyProcPid;
beentry->st_proc_start_timestamp = proc_start_timestamp;
beentry->st_activity_start_timestamp = 0;
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
beentry->st_state_start_timestamp = 0;
Rename recently-added pg_stat_activity column from txn_start to xact_start, for consistency with other column names such as in pg_stat_database.
2007-09-11 05:28:05 +02:00
beentry->st_xact_start_timestamp = 0;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
beentry->st_databaseid = MyDatabaseId;
beentry->st_userid = userid;
beentry->st_clientaddr = clientaddr;
Fix bugs in manipulation of PgBackendStatus.st_clienthostname. Initialization of this field was not being done according to the st_changecount protocol (it has to be done within the changecount increment range, not outside). And the test to see if the value should be reported as null was wrong. Noted while perusing uses of Port.remote_hostname. This was wrong from the introduction of this code (commit 4a25bc145), so back-patch to 9.1.
2014-04-02 03:30:08 +02:00
if (MyProcPort && MyProcPort->remote_hostname)
strlcpy(beentry->st_clienthostname, MyProcPort->remote_hostname,
NAMEDATALEN);
else
beentry->st_clienthostname[0] = '\0';
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
#ifdef USE_SSL
if (MyProcPort && MyProcPort->ssl != NULL)
{
beentry->st_ssl = true;
beentry->st_sslstatus->ssl_bits = be_tls_get_cipher_bits(MyProcPort);
beentry->st_sslstatus->ssl_compression = be_tls_get_compression(MyProcPort);
be_tls_get_version(MyProcPort, beentry->st_sslstatus->ssl_version, NAMEDATALEN);
be_tls_get_cipher(MyProcPort, beentry->st_sslstatus->ssl_cipher, NAMEDATALEN);
be_tls_get_peerdn_name(MyProcPort, beentry->st_sslstatus->ssl_clientdn, NAMEDATALEN);
}
else
{
beentry->st_ssl = false;
}
#else
beentry->st_ssl = false;
#endif
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
beentry->st_state = STATE_UNDEFINED;
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
beentry->st_appname[0] = '\0';
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
beentry->st_activity[0] = '\0';
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
/* Also make sure the last byte in each string area is always 0 */
Add client_hostname field to pg_stat_activity. Peter Eisentraut, reviewed by Steve Singer, Alvaro Herrera, and me.
2011-02-17 22:03:28 +01:00
beentry->st_clienthostname[NAMEDATALEN - 1] = '\0';
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
beentry->st_appname[NAMEDATALEN - 1] = '\0';
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
beentry->st_activity[pgstat_track_activity_query_size - 1] = '\0';
Add a generic command progress reporting facility. Using this facility, any utility command can report the target relation upon which it is operating, if there is one, and up to 10 64-bit counters; the intent of this is that users should be able to figure out what a utility command is doing without having to resort to ugly hacks like attaching strace to a backend. As a demonstration, this adds very crude reporting to lazy vacuum; we just report the target relation and nothing else. A forthcoming patch will make VACUUM report a bunch of additional data that will make this much more interesting. But this gets the basic framework in place. Vinayak Pokale, Rahila Syed, Amit Langote, Robert Haas, reviewed by Kyotaro Horiguchi, Jim Nasby, Thom Brown, Masahiko Sawada, Fujii Masao, and Masanori Oyama.
2016-03-09 18:08:58 +01:00
beentry->st_progress_command = PROGRESS_COMMAND_INVALID;
beentry->st_progress_command_target = InvalidOid;
/*
* we don't zero st_progress_param here to save cycles; nobody should
* examine it until st_progress_command has been set to something other
* than PROGRESS_COMMAND_INVALID
*/
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_after(beentry);
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
/* Update app name to current GUC setting */
if (application_name)
pgstat_report_appname(application_name);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
}
/*
* Shut down a single backend's statistics reporting at process exit.
*
* Flush any remaining statistics counts out to the collector.
* Without this, operations triggered during backend exit (such as
* temp table deletions) won't be counted.
*
* Lastly, clear out our entry in the PgBackendStatus array.
*/
static void
pgstat_beshutdown_hook(int code, Datum arg)
{
Fix pgstat_report_waiting() to not dump core if called before pgstat_bestart() has been called; else any lock-block occurring during InitPostgres() is disastrous. I believe this explains recent wasp regression failure; at least it explains the crash I got while trying to duplicate the problem. I also made pgstat_report_activity() safe against the same scenario, just in case. The report_waiting hazard was created by my patch of 19-Aug to include waiting status in pg_stat_activity.
2006-08-28 21:38:09 +02:00
volatile PgBackendStatus *beentry = MyBEEntry;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Allow backends to start up without use of the flat-file copy of pg_database. To make this work in the base case, pg_database now has a nailed-in-cache relation descriptor that is initialized using hardwired knowledge in relcache.c. This means pg_database is added to the set of relations that need to have a Schema_pg_xxx macro maintained in pg_attribute.h. When this path is taken, we'll have to do a seqscan of pg_database to find the row we need. In the normal case, we are able to do an indexscan to find the database's row by name. This is made possible by storing a global relcache init file that describes only the shared catalogs and their indexes (and therefore is usable by all backends in any database). A new backend loads this cache file, finds its database OID after an indexscan on pg_database, and then loads the local relcache init file for that database. This change should effectively eliminate number of databases as a factor in backend startup time, even with large numbers of databases. However, the real reason for doing it is as a first step towards getting rid of the flat files altogether. There are still several other sub-projects to be tackled before that can happen.
2009-08-12 22:53:31 +02:00
/*
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
* If we got as far as discovering our own database ID, we can report what
* we did to the collector. Otherwise, we'd be sending an invalid
Allow backends to start up without use of the flat-file copy of pg_database. To make this work in the base case, pg_database now has a nailed-in-cache relation descriptor that is initialized using hardwired knowledge in relcache.c. This means pg_database is added to the set of relations that need to have a Schema_pg_xxx macro maintained in pg_attribute.h. When this path is taken, we'll have to do a seqscan of pg_database to find the row we need. In the normal case, we are able to do an indexscan to find the database's row by name. This is made possible by storing a global relcache init file that describes only the shared catalogs and their indexes (and therefore is usable by all backends in any database). A new backend loads this cache file, finds its database OID after an indexscan on pg_database, and then loads the local relcache init file for that database. This change should effectively eliminate number of databases as a factor in backend startup time, even with large numbers of databases. However, the real reason for doing it is as a first step towards getting rid of the flat files altogether. There are still several other sub-projects to be tackled before that can happen.
2009-08-12 22:53:31 +02:00
* database ID, so forget it. (This means that accesses to pg_database
* during failed backend starts might never get counted.)
*/
if (OidIsValid(MyDatabaseId))
pgstat_report_stat(true);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* Clear my status entry, following the protocol of bumping st_changecount
* before and after. We use a volatile pointer here to ensure the
* compiler doesn't try to get cute.
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
*/
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_before(beentry);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
beentry->st_procpid = 0; /* mark invalid */
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_after(beentry);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
}
/* ----------
* pgstat_report_activity() -
*
* Called from tcop/postgres.c to report what the backend is actually doing
Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
2013-04-03 20:13:28 +02:00
* (but note cmd_str can be NULL for certain cases).
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
*
* All updates of the status entry follow the protocol of bumping
* st_changecount before and after. We use a volatile pointer here to
* ensure the compiler doesn't try to get cute.
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
* ----------
*/
void
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
pgstat_report_activity(BackendState state, const char *cmd_str)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
{
Fix pgstat_report_waiting() to not dump core if called before pgstat_bestart() has been called; else any lock-block occurring during InitPostgres() is disastrous. I believe this explains recent wasp regression failure; at least it explains the crash I got while trying to duplicate the problem. I also made pgstat_report_activity() safe against the same scenario, just in case. The report_waiting hazard was created by my patch of 19-Aug to include waiting status in pg_stat_activity.
2006-08-28 21:38:09 +02:00
volatile PgBackendStatus *beentry = MyBEEntry;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
TimestampTz start_timestamp;
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
TimestampTz current_timestamp;
Suppress possibly-uninitialized-variable warning seen with older gcc versions.
2012-01-24 19:40:26 +01:00
int len = 0;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Add a few more DTrace probes to the backend. Robert Lor
2008-08-01 15:16:09 +02:00
TRACE_POSTGRESQL_STATEMENT_STATUS(cmd_str);
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
if (!beentry)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
return;
Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
2013-04-03 20:13:28 +02:00
if (!pgstat_track_activities)
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
{
Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
2013-04-03 20:13:28 +02:00
if (beentry->st_state != STATE_DISABLED)
{
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
volatile PGPROC *proc = MyProc;
Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
2013-04-03 20:13:28 +02:00
/*
* track_activities is disabled, but we last reported a
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* non-disabled state. As our final update, change the state and
Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
2013-04-03 20:13:28 +02:00
* clear fields we will not be updating anymore.
*/
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_before(beentry);
Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
2013-04-03 20:13:28 +02:00
beentry->st_state = STATE_DISABLED;
beentry->st_state_start_timestamp = 0;
beentry->st_activity[0] = '\0';
beentry->st_activity_start_timestamp = 0;
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
/* st_xact_start_timestamp and wait_event_info are also disabled */
Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
2013-04-03 20:13:28 +02:00
beentry->st_xact_start_timestamp = 0;
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
proc->wait_event_info = 0;
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_after(beentry);
Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
2013-04-03 20:13:28 +02:00
}
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
return;
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/*
Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
2013-04-03 20:13:28 +02:00
* To minimize the time spent modifying the entry, fetch all the needed
* data first.
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
*/
start_timestamp = GetCurrentStatementStartTimestamp();
if (cmd_str != NULL)
{
Suppress possibly-uninitialized-variable warning seen with older gcc versions.
2012-01-24 19:40:26 +01:00
len = pg_mbcliplen(cmd_str, strlen(cmd_str),
pgstat_track_activity_query_size - 1);
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
}
Avoid updating our PgBackendStatus entry when track_activities is off. The point of turning off track_activities is to avoid this reporting overhead, but a thinko in commit 4f42b546fd87a80be30c53a0f2c897acb826ad52 caused pgstat_report_activity() to perform half of its updates anyway. Fix that, and also make sure that we clear all the now-disabled fields when transitioning to the non-reporting state.
2013-04-03 20:13:28 +02:00
current_timestamp = GetCurrentTimestamp();
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
/*
* Now update the status entry
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
*/
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_before(beentry);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Separate state from query string in pg_stat_activity This separates the state (running/idle/idleintransaction etc) into it's own field ("state"), and leaves the query field containing just query text. The query text will now mean "current query" when a query is running and "last query" in other states. Accordingly,the field has been renamed from current_query to query. Since backwards compatibility was broken anyway to make that, the procpid field has also been renamed to pid - along with the same field in pg_stat_replication for consistency. Scott Mead and Magnus Hagander, review work from Greg Smith
2012-01-19 14:19:20 +01:00
beentry->st_state = state;
beentry->st_state_start_timestamp = current_timestamp;
if (cmd_str != NULL)
{
memcpy((char *) beentry->st_activity, cmd_str, len);
beentry->st_activity[len] = '\0';
beentry->st_activity_start_timestamp = start_timestamp;
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_after(beentry);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
}
Add a generic command progress reporting facility. Using this facility, any utility command can report the target relation upon which it is operating, if there is one, and up to 10 64-bit counters; the intent of this is that users should be able to figure out what a utility command is doing without having to resort to ugly hacks like attaching strace to a backend. As a demonstration, this adds very crude reporting to lazy vacuum; we just report the target relation and nothing else. A forthcoming patch will make VACUUM report a bunch of additional data that will make this much more interesting. But this gets the basic framework in place. Vinayak Pokale, Rahila Syed, Amit Langote, Robert Haas, reviewed by Kyotaro Horiguchi, Jim Nasby, Thom Brown, Masahiko Sawada, Fujii Masao, and Masanori Oyama.
2016-03-09 18:08:58 +01:00
/*-----------
* pgstat_progress_start_command() -
*
Code review for b6fb6471f6afaf649e52f38269fd8c5c60647669. Reports by Tomas Vondra, Vinayak Pokale, and Aleksander Alekseev. Patch by Amit Langote.
2016-03-10 12:07:57 +01:00
* Set st_progress_command (and st_progress_command_target) in own backend
* entry. Also, zero-initialize st_progress_param array.
Add a generic command progress reporting facility. Using this facility, any utility command can report the target relation upon which it is operating, if there is one, and up to 10 64-bit counters; the intent of this is that users should be able to figure out what a utility command is doing without having to resort to ugly hacks like attaching strace to a backend. As a demonstration, this adds very crude reporting to lazy vacuum; we just report the target relation and nothing else. A forthcoming patch will make VACUUM report a bunch of additional data that will make this much more interesting. But this gets the basic framework in place. Vinayak Pokale, Rahila Syed, Amit Langote, Robert Haas, reviewed by Kyotaro Horiguchi, Jim Nasby, Thom Brown, Masahiko Sawada, Fujii Masao, and Masanori Oyama.
2016-03-09 18:08:58 +01:00
*-----------
*/
void
pgstat_progress_start_command(ProgressCommandType cmdtype, Oid relid)
{
volatile PgBackendStatus *beentry = MyBEEntry;
if (!beentry || !pgstat_track_activities)
return;
pgstat_increment_changecount_before(beentry);
beentry->st_progress_command = cmdtype;
beentry->st_progress_command_target = relid;
MemSet(&beentry->st_progress_param, 0, sizeof(beentry->st_progress_param));
pgstat_increment_changecount_after(beentry);
}
/*-----------
* pgstat_progress_update_param() -
*
* Update index'th member in st_progress_param[] of own backend entry.
*-----------
*/
void
pgstat_progress_update_param(int index, int64 val)
{
volatile PgBackendStatus *beentry = MyBEEntry;
Assert(index >= 0 && index < PGSTAT_NUM_PROGRESS_PARAM);
if (!beentry || !pgstat_track_activities)
return;
pgstat_increment_changecount_before(beentry);
beentry->st_progress_param[index] = val;
pgstat_increment_changecount_after(beentry);
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
}
/*-----------
Fix problems in commit c16dc1aca5e01e6acaadfcf38f5fc964a381dc62. Vinayak Pokale provided a patch for a copy-and-paste error in a comment. I noticed that I'd use the word "automatically" nearby where I meant to talk about things being "atomic". Rahila Syed spotted a misplaced counter update. Fix all that stuff.
2016-03-16 18:54:04 +01:00
* pgstat_progress_update_multi_param() -
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
*
Another comment update. I thought this was in my last commit, but I goofed.
2016-03-16 19:28:25 +01:00
* Update multiple members in st_progress_param[] of own backend entry.
* This is atomic; readers won't see intermediate states.
Add simple VACUUM progress reporting. There's a lot more that could be done here yet - in particular, this reports only very coarse-grained information about the index vacuuming phase - but even as it stands, the new pg_stat_progress_vacuum can tell you quite a bit about what a long-running vacuum is actually doing. Amit Langote and Robert Haas, based on earlier work by Vinayak Pokale and Rahila Syed.
2016-03-15 18:31:18 +01:00
*-----------
*/
void
pgstat_progress_update_multi_param(int nparam, const int *index,
const int64 *val)
{
volatile PgBackendStatus *beentry = MyBEEntry;
int i;
if (!beentry || !pgstat_track_activities || nparam == 0)
return;
pgstat_increment_changecount_before(beentry);
for (i = 0; i < nparam; ++i)
{
Assert(index[i] >= 0 && index[i] < PGSTAT_NUM_PROGRESS_PARAM);
beentry->st_progress_param[index[i]] = val[i];
}
pgstat_increment_changecount_after(beentry);
Add a generic command progress reporting facility. Using this facility, any utility command can report the target relation upon which it is operating, if there is one, and up to 10 64-bit counters; the intent of this is that users should be able to figure out what a utility command is doing without having to resort to ugly hacks like attaching strace to a backend. As a demonstration, this adds very crude reporting to lazy vacuum; we just report the target relation and nothing else. A forthcoming patch will make VACUUM report a bunch of additional data that will make this much more interesting. But this gets the basic framework in place. Vinayak Pokale, Rahila Syed, Amit Langote, Robert Haas, reviewed by Kyotaro Horiguchi, Jim Nasby, Thom Brown, Masahiko Sawada, Fujii Masao, and Masanori Oyama.
2016-03-09 18:08:58 +01:00
}
/*-----------
* pgstat_progress_end_command() -
*
Code review for b6fb6471f6afaf649e52f38269fd8c5c60647669. Reports by Tomas Vondra, Vinayak Pokale, and Aleksander Alekseev. Patch by Amit Langote.
2016-03-10 12:07:57 +01:00
* Reset st_progress_command (and st_progress_command_target) in own backend
* entry. This signals the end of the command.
Add a generic command progress reporting facility. Using this facility, any utility command can report the target relation upon which it is operating, if there is one, and up to 10 64-bit counters; the intent of this is that users should be able to figure out what a utility command is doing without having to resort to ugly hacks like attaching strace to a backend. As a demonstration, this adds very crude reporting to lazy vacuum; we just report the target relation and nothing else. A forthcoming patch will make VACUUM report a bunch of additional data that will make this much more interesting. But this gets the basic framework in place. Vinayak Pokale, Rahila Syed, Amit Langote, Robert Haas, reviewed by Kyotaro Horiguchi, Jim Nasby, Thom Brown, Masahiko Sawada, Fujii Masao, and Masanori Oyama.
2016-03-09 18:08:58 +01:00
*-----------
*/
void
pgstat_progress_end_command(void)
{
volatile PgBackendStatus *beentry = MyBEEntry;
if (!beentry)
return;
if (!pgstat_track_activities
&& beentry->st_progress_command == PROGRESS_COMMAND_INVALID)
return;
pgstat_increment_changecount_before(beentry);
beentry->st_progress_command = PROGRESS_COMMAND_INVALID;
beentry->st_progress_command_target = InvalidOid;
pgstat_increment_changecount_after(beentry);
}
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
/* ----------
* pgstat_report_appname() -
*
* Called to update our application name.
* ----------
*/
void
pgstat_report_appname(const char *appname)
{
volatile PgBackendStatus *beentry = MyBEEntry;
int len;
if (!beentry)
return;
/* This should be unnecessary if GUC did its job, but be safe */
len = pg_mbcliplen(appname, strlen(appname), NAMEDATALEN - 1);
/*
* Update my status entry, following the protocol of bumping
* st_changecount before and after. We use a volatile pointer here to
* ensure the compiler doesn't try to get cute.
*/
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_before(beentry);
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
memcpy((char *) beentry->st_appname, appname, len);
beentry->st_appname[len] = '\0';
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_after(beentry);
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
}
Add a txn_start column to pg_stat_activity. This makes it easier to identify long-running transactions. Since we already need to record the transaction-start time (e.g. for now()), we don't need any additional system calls to report this information. Catversion bumped, initdb required.
2006-12-06 19:06:48 +01:00
/*
Rename recently-added pg_stat_activity column from txn_start to xact_start, for consistency with other column names such as in pg_stat_database.
2007-09-11 05:28:05 +02:00
* Report current transaction start timestamp as the specified value.
* Zero means there is no active transaction.
Add a txn_start column to pg_stat_activity. This makes it easier to identify long-running transactions. Since we already need to record the transaction-start time (e.g. for now()), we don't need any additional system calls to report this information. Catversion bumped, initdb required.
2006-12-06 19:06:48 +01:00
*/
void
Rename recently-added pg_stat_activity column from txn_start to xact_start, for consistency with other column names such as in pg_stat_database.
2007-09-11 05:28:05 +02:00
pgstat_report_xact_timestamp(TimestampTz tstamp)
Add a txn_start column to pg_stat_activity. This makes it easier to identify long-running transactions. Since we already need to record the transaction-start time (e.g. for now()), we don't need any additional system calls to report this information. Catversion bumped, initdb required.
2006-12-06 19:06:48 +01:00
{
volatile PgBackendStatus *beentry = MyBEEntry;
Simplify and rename some GUC variables, per various recent discussions: * stats_start_collector goes away; we always start the collector process, unless prevented by a problem with setting up the stats UDP socket. * stats_reset_on_server_start goes away; it seems useless in view of the availability of pg_stat_reset(). * stats_block_level and stats_row_level are merged into a single variable "track_counts", which controls all reports sent to the collector process. * stats_command_string is renamed to track_activities. * log_autovacuum is renamed to log_autovacuum_min_duration to better reflect its meaning. The log_autovacuum change is not a compatibility issue since it didn't exist before 8.3 anyway. The other changes need to be release-noted.
2007-09-24 05:12:23 +02:00
if (!pgstat_track_activities || !beentry)
Add a txn_start column to pg_stat_activity. This makes it easier to identify long-running transactions. Since we already need to record the transaction-start time (e.g. for now()), we don't need any additional system calls to report this information. Catversion bumped, initdb required.
2006-12-06 19:06:48 +01:00
return;
/*
* Update my status entry, following the protocol of bumping
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* st_changecount before and after. We use a volatile pointer here to
* ensure the compiler doesn't try to get cute.
Add a txn_start column to pg_stat_activity. This makes it easier to identify long-running transactions. Since we already need to record the transaction-start time (e.g. for now()), we don't need any additional system calls to report this information. Catversion bumped, initdb required.
2006-12-06 19:06:48 +01:00
*/
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_before(beentry);
Rename recently-added pg_stat_activity column from txn_start to xact_start, for consistency with other column names such as in pg_stat_database.
2007-09-11 05:28:05 +02:00
beentry->st_xact_start_timestamp = tstamp;
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_increment_changecount_after(beentry);
Add a txn_start column to pg_stat_activity. This makes it easier to identify long-running transactions. Since we already need to record the transaction-start time (e.g. for now()), we don't need any additional system calls to report this information. Catversion bumped, initdb required.
2006-12-06 19:06:48 +01:00
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/* ----------
* pgstat_read_current_status() -
*
* Copy the current contents of the PgBackendStatus array to local memory,
* if not already done in this transaction.
* ----------
*/
static void
pgstat_read_current_status(void)
{
volatile PgBackendStatus *beentry;
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
LocalPgBackendStatus *localtable;
LocalPgBackendStatus *localentry;
Further code review for pg_stat_ssl patch. Fix additional bogosity in commit 9029f4b37406b21a. Include the BackendSslStatusBuffer in the BackendStatusShmemSize calculation, avoid ugly and error-prone casts to char* and back, put related code stanzas into a consistent order (and fix a couple of previous instances of that sin). All cosmetic except for the size oversight.
2015-07-27 22:29:14 +02:00
char *localappname,
*localactivity;
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
#ifdef USE_SSL
PgBackendSSLStatus *localsslstatus;
#endif
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
int i;
Assert(!pgStatRunningInCollector);
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
if (localBackendStatusTable)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
return; /* already done */
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
pgstat_setup_memcxt();
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
localtable = (LocalPgBackendStatus *)
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
MemoryContextAlloc(pgStatLocalContext,
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
sizeof(LocalPgBackendStatus) * MaxBackends);
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
localappname = (char *)
MemoryContextAlloc(pgStatLocalContext,
NAMEDATALEN * MaxBackends);
Further code review for pg_stat_ssl patch. Fix additional bogosity in commit 9029f4b37406b21a. Include the BackendSslStatusBuffer in the BackendStatusShmemSize calculation, avoid ugly and error-prone casts to char* and back, put related code stanzas into a consistent order (and fix a couple of previous instances of that sin). All cosmetic except for the size oversight.
2015-07-27 22:29:14 +02:00
localactivity = (char *)
MemoryContextAlloc(pgStatLocalContext,
pgstat_track_activity_query_size * MaxBackends);
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
#ifdef USE_SSL
localsslstatus = (PgBackendSSLStatus *)
MemoryContextAlloc(pgStatLocalContext,
sizeof(PgBackendSSLStatus) * MaxBackends);
#endif
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
localNumBackends = 0;
beentry = BackendStatusArray;
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
localentry = localtable;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
for (i = 1; i <= MaxBackends; i++)
{
/*
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
* Follow the protocol of retrying if st_changecount changes while we
* copy the entry, or if it's odd. (The check for odd is needed to
* cover the case where we are able to completely copy the entry while
* the source backend is between increment steps.) We use a volatile
* pointer here to ensure the compiler doesn't try to get cute.
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
*/
for (;;)
{
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
int before_changecount;
int after_changecount;
pgstat_save_changecount_before(beentry, before_changecount);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
localentry->backendStatus.st_procpid = beentry->st_procpid;
if (localentry->backendStatus.st_procpid > 0)
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
{
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
memcpy(&localentry->backendStatus, (char *) beentry, sizeof(PgBackendStatus));
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
/*
* strcpy is safe even if the string is modified concurrently,
* because there's always a \0 at the end of the buffer.
*/
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
strcpy(localappname, (char *) beentry->st_appname);
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
localentry->backendStatus.st_appname = localappname;
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
strcpy(localactivity, (char *) beentry->st_activity);
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
localentry->backendStatus.st_activity = localactivity;
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
localentry->backendStatus.st_ssl = beentry->st_ssl;
#ifdef USE_SSL
if (beentry->st_ssl)
{
memcpy(localsslstatus, beentry->st_sslstatus, sizeof(PgBackendSSLStatus));
localentry->backendStatus.st_sslstatus = localsslstatus;
}
#endif
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_save_changecount_after(beentry, after_changecount);
if (before_changecount == after_changecount &&
(before_changecount & 1) == 0)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
break;
/* Make sure we can break out of loop if stuck... */
CHECK_FOR_INTERRUPTS();
}
beentry++;
/* Only valid entries get included into the local array */
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
if (localentry->backendStatus.st_procpid > 0)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
{
Show xid and xmin in pg_stat_activity and pg_stat_replication. Christian Kruse, reviewed by Andres Freund and myself, with further minor adjustments by me.
2014-02-25 18:34:04 +01:00
BackendIdGetTransactionIds(i,
&localentry->backend_xid,
&localentry->backend_xmin);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
localentry++;
Add support for an application_name parameter, which is displayed in pg_stat_activity and recorded in log entries. Dave Page, reviewed by Andres Freund
2009-11-29 00:38:08 +01:00
localappname += NAMEDATALEN;
Turn PGBE_ACTIVITY_SIZE into a GUC variable, track_activity_query_size. As the buffer could now be a lot larger than before, and copying it could thus be a lot more expensive than before, use strcpy instead of memcpy to copy the query string, as was already suggested in comments. Also, only copy the PgBackendStatus struct and string if the slot is in use. Patch by Thomas Lee, with some changes by me.
2008-06-30 12:58:47 +02:00
localactivity += pgstat_track_activity_query_size;
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
#ifdef USE_SSL
Fix pointer-arithmetic thinko in pg_stat_ssl patch. Nasty memory-stomp bug in commit 9029f4b37406b21a. It's not apparent how this survived even cursory testing :-(. Per report from Peter Holzer.
2015-07-27 21:58:46 +02:00
localsslstatus++;
Add system view pg_stat_ssl This view shows information about all connections, such as if the connection is using SSL, which cipher is used, and which client certificate (if any) is used. Reviews by Alex Shulgin, Heikki Linnakangas, Andres Freund & Michael Paquier
2015-04-12 19:07:46 +02:00
#endif
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
localNumBackends++;
}
}
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
/* Set the pointer only after completion of a valid table */
localBackendStatusTable = localtable;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
}
Provide much better wait information in pg_stat_activity. When a process is waiting for a heavyweight lock, we will now indicate the type of heavyweight lock for which it is waiting. Also, you can now see when a process is waiting for a lightweight lock - in which case we will indicate the individual lock name or the tranche, as appropriate - or for a buffer pin. Amit Kapila, Ildus Kurbangaliev, reviewed by me. Lots of helpful discussion and suggestions by many others, including Alexander Korotkov, Vladimir Borodin, and many others.
2016-03-10 18:44:09 +01:00
/* ----------
* pgstat_get_wait_event_type() -
*
* Return a string representing the current wait event type, backend is
* waiting on.
*/
const char *
pgstat_get_wait_event_type(uint32 wait_event_info)
{
uint8 classId;
const char *event_type;
/* report process as not waiting. */
if (wait_event_info == 0)
return NULL;
wait_event_info = wait_event_info >> 24;
classId = wait_event_info & 0XFF;
switch (classId)
{
case WAIT_LWLOCK_NAMED:
event_type = "LWLockNamed";
break;
case WAIT_LWLOCK_TRANCHE:
event_type = "LWLockTranche";
break;
case WAIT_LOCK:
event_type = "Lock";
break;
case WAIT_BUFFER_PIN:
event_type = "BufferPin";
break;
default:
event_type = "???";
break;
}
return event_type;
}
/* ----------
* pgstat_get_wait_event() -
*
* Return a string representing the current wait event, backend is
* waiting on.
*/
const char *
pgstat_get_wait_event(uint32 wait_event_info)
{
uint8 classId;
uint16 eventId;
const char *event_name;
/* report process as not waiting. */
if (wait_event_info == 0)
return NULL;
eventId = wait_event_info & ((1 << 24) - 1);
wait_event_info = wait_event_info >> 24;
classId = wait_event_info & 0XFF;
switch (classId)
{
case WAIT_LWLOCK_NAMED:
case WAIT_LWLOCK_TRANCHE:
event_name = GetLWLockIdentifier(classId, eventId);
break;
case WAIT_LOCK:
event_name = GetLockNameFromTagType(eventId);
break;
case WAIT_BUFFER_PIN:
event_name = "BufferPin";
break;
default:
event_name = "unknown wait event";
break;
}
return event_name;
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Report the current queries of all backends involved in a deadlock (if they'd be visible to the current user in pg_stat_activity). This might look like it's subject to race conditions, but it's actually pretty safe because at the time DeadLockReport() is constructing the report, we haven't yet aborted our transaction and so we can expect that everyone else involved in the deadlock is still blocked on some lock. (There are corner cases where that might not be true, such as a statement timeout triggering in another backend before we finish reporting; but at worst we'd report a misleading activity string, so it seems acceptable considering the usefulness of reporting the queries.) Original patch by Itagaki Takahiro, heavily modified by me.
2008-03-21 22:08:31 +01:00
/* ----------
* pgstat_get_backend_current_activity() -
*
* Return a string representing the current activity of the backend with
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* the specified PID. This looks directly at the BackendStatusArray,
Report the current queries of all backends involved in a deadlock (if they'd be visible to the current user in pg_stat_activity). This might look like it's subject to race conditions, but it's actually pretty safe because at the time DeadLockReport() is constructing the report, we haven't yet aborted our transaction and so we can expect that everyone else involved in the deadlock is still blocked on some lock. (There are corner cases where that might not be true, such as a statement timeout triggering in another backend before we finish reporting; but at worst we'd report a misleading activity string, so it seems acceptable considering the usefulness of reporting the queries.) Original patch by Itagaki Takahiro, heavily modified by me.
2008-03-21 22:08:31 +01:00
* and so will provide current information regardless of the age of our
* transaction's snapshot of the status array.
*
* It is the caller's responsibility to invoke this only for backends whose
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* state is expected to remain stable while the result is in use. The
Report the current queries of all backends involved in a deadlock (if they'd be visible to the current user in pg_stat_activity). This might look like it's subject to race conditions, but it's actually pretty safe because at the time DeadLockReport() is constructing the report, we haven't yet aborted our transaction and so we can expect that everyone else involved in the deadlock is still blocked on some lock. (There are corner cases where that might not be true, such as a statement timeout triggering in another backend before we finish reporting; but at worst we'd report a misleading activity string, so it seems acceptable considering the usefulness of reporting the queries.) Original patch by Itagaki Takahiro, heavily modified by me.
2008-03-21 22:08:31 +01:00
* only current use is in deadlock reporting, where we can expect that
* the target backend is blocked on a lock. (There are corner cases
* where the target's wait could get aborted while we are looking at it,
* but the very worst consequence is to return a pointer to a string
* that's been changed, so we won't worry too much.)
*
* Note: return strings for special cases match pg_stat_get_backend_activity.
* ----------
*/
const char *
Adjust the recent patch for reporting of deadlocked queries so that we report query texts only to the server log. This eliminates the issue of possible leaking of security-sensitive data in other sessions' queries. Since the log is presumed secure, we can now log the queries of all sessions involved in the deadlock, whether or not they belong to the same user as the one reporting the failure.
2008-03-24 19:22:36 +01:00
pgstat_get_backend_current_activity(int pid, bool checkUser)
Report the current queries of all backends involved in a deadlock (if they'd be visible to the current user in pg_stat_activity). This might look like it's subject to race conditions, but it's actually pretty safe because at the time DeadLockReport() is constructing the report, we haven't yet aborted our transaction and so we can expect that everyone else involved in the deadlock is still blocked on some lock. (There are corner cases where that might not be true, such as a statement timeout triggering in another backend before we finish reporting; but at worst we'd report a misleading activity string, so it seems acceptable considering the usefulness of reporting the queries.) Original patch by Itagaki Takahiro, heavily modified by me.
2008-03-21 22:08:31 +01:00
{
PgBackendStatus *beentry;
int i;
beentry = BackendStatusArray;
for (i = 1; i <= MaxBackends; i++)
{
/*
* Although we expect the target backend's entry to be stable, that
* doesn't imply that anyone else's is. To avoid identifying the
* wrong backend, while we check for a match to the desired PID we
* must follow the protocol of retrying if st_changecount changes
* while we examine the entry, or if it's odd. (This might be
* unnecessary, since fetching or storing an int is almost certainly
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* atomic, but let's play it safe.) We use a volatile pointer here to
* ensure the compiler doesn't try to get cute.
Report the current queries of all backends involved in a deadlock (if they'd be visible to the current user in pg_stat_activity). This might look like it's subject to race conditions, but it's actually pretty safe because at the time DeadLockReport() is constructing the report, we haven't yet aborted our transaction and so we can expect that everyone else involved in the deadlock is still blocked on some lock. (There are corner cases where that might not be true, such as a statement timeout triggering in another backend before we finish reporting; but at worst we'd report a misleading activity string, so it seems acceptable considering the usefulness of reporting the queries.) Original patch by Itagaki Takahiro, heavily modified by me.
2008-03-21 22:08:31 +01:00
*/
volatile PgBackendStatus *vbeentry = beentry;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
bool found;
Report the current queries of all backends involved in a deadlock (if they'd be visible to the current user in pg_stat_activity). This might look like it's subject to race conditions, but it's actually pretty safe because at the time DeadLockReport() is constructing the report, we haven't yet aborted our transaction and so we can expect that everyone else involved in the deadlock is still blocked on some lock. (There are corner cases where that might not be true, such as a statement timeout triggering in another backend before we finish reporting; but at worst we'd report a misleading activity string, so it seems acceptable considering the usefulness of reporting the queries.) Original patch by Itagaki Takahiro, heavily modified by me.
2008-03-21 22:08:31 +01:00
for (;;)
{
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
int before_changecount;
int after_changecount;
pgstat_save_changecount_before(vbeentry, before_changecount);
Report the current queries of all backends involved in a deadlock (if they'd be visible to the current user in pg_stat_activity). This might look like it's subject to race conditions, but it's actually pretty safe because at the time DeadLockReport() is constructing the report, we haven't yet aborted our transaction and so we can expect that everyone else involved in the deadlock is still blocked on some lock. (There are corner cases where that might not be true, such as a statement timeout triggering in another backend before we finish reporting; but at worst we'd report a misleading activity string, so it seems acceptable considering the usefulness of reporting the queries.) Original patch by Itagaki Takahiro, heavily modified by me.
2008-03-21 22:08:31 +01:00
found = (vbeentry->st_procpid == pid);
Add memory barriers for PgBackendStatus.st_changecount protocol. st_changecount protocol needs the memory barriers to ensure that the apparent order of execution is as it desires. Otherwise, for example, the CPU might rearrange the code so that st_changecount is incremented twice before the modification on a machine with weak memory ordering. This surprising result can lead to bugs. This commit introduces the macros to load and store st_changecount with the memory barriers. These are called before and after PgBackendStatus entries are modified or copied into private memory, in order to prevent CPU from reordering PgBackendStatus access. Per discussion on pgsql-hackers, we decided not to back-patch this to 9.4 or before until we get an actual bug report about this. Patch by me. Review by Robert Haas.
2014-12-18 15:07:51 +01:00
pgstat_save_changecount_after(vbeentry, after_changecount);
if (before_changecount == after_changecount &&
(before_changecount & 1) == 0)
Report the current queries of all backends involved in a deadlock (if they'd be visible to the current user in pg_stat_activity). This might look like it's subject to race conditions, but it's actually pretty safe because at the time DeadLockReport() is constructing the report, we haven't yet aborted our transaction and so we can expect that everyone else involved in the deadlock is still blocked on some lock. (There are corner cases where that might not be true, such as a statement timeout triggering in another backend before we finish reporting; but at worst we'd report a misleading activity string, so it seems acceptable considering the usefulness of reporting the queries.) Original patch by Itagaki Takahiro, heavily modified by me.
2008-03-21 22:08:31 +01:00
break;
/* Make sure we can break out of loop if stuck... */
CHECK_FOR_INTERRUPTS();
}
if (found)
{
/* Now it is safe to use the non-volatile pointer */
Adjust the recent patch for reporting of deadlocked queries so that we report query texts only to the server log. This eliminates the issue of possible leaking of security-sensitive data in other sessions' queries. Since the log is presumed secure, we can now log the queries of all sessions involved in the deadlock, whether or not they belong to the same user as the one reporting the failure.
2008-03-24 19:22:36 +01:00
if (checkUser && !superuser() && beentry->st_userid != GetUserId())
Report the current queries of all backends involved in a deadlock (if they'd be visible to the current user in pg_stat_activity). This might look like it's subject to race conditions, but it's actually pretty safe because at the time DeadLockReport() is constructing the report, we haven't yet aborted our transaction and so we can expect that everyone else involved in the deadlock is still blocked on some lock. (There are corner cases where that might not be true, such as a statement timeout triggering in another backend before we finish reporting; but at worst we'd report a misleading activity string, so it seems acceptable considering the usefulness of reporting the queries.) Original patch by Itagaki Takahiro, heavily modified by me.
2008-03-21 22:08:31 +01:00
return "<insufficient privilege>";
else if (*(beentry->st_activity) == '\0')
return "<command string not enabled>";
else
return beentry->st_activity;
}
beentry++;
}
/* If we get here, caller is in error ... */
return "<backend information not available>";
}
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
/* ----------
* pgstat_get_crashed_backend_activity() -
*
* Return a string representing the current activity of the backend with
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* the specified PID. Like the function above, but reads shared memory with
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
* the expectation that it may be corrupt. On success, copy the string
* into the "buffer" argument and return that pointer. On failure,
* return NULL.
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
*
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
* This function is only intended to be used by the postmaster to report the
* query that crashed a backend. In particular, no attempt is made to
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
* follow the correct concurrency protocol when accessing the
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
* BackendStatusArray. But that's OK, in the worst case we'll return a
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* corrupted message. We also must take care not to trip on ereport(ERROR).
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
* ----------
*/
const char *
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
pgstat_get_crashed_backend_activity(int pid, char *buffer, int buflen)
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
{
volatile PgBackendStatus *beentry;
int i;
beentry = BackendStatusArray;
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
/*
* We probably shouldn't get here before shared memory has been set up,
* but be safe.
*/
if (beentry == NULL || BackendActivityBuffer == NULL)
return NULL;
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
for (i = 1; i <= MaxBackends; i++)
{
if (beentry->st_procpid == pid)
{
/* Read pointer just once, so it can't change after validation */
const char *activity = beentry->st_activity;
const char *activity_last;
/*
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
* We mustn't access activity string before we verify that it
* falls within the BackendActivityBuffer. To make sure that the
* entire string including its ending is contained within the
* buffer, subtract one activity length from the buffer size.
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
*/
activity_last = BackendActivityBuffer + BackendActivityBufferSize
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
- pgstat_track_activity_query_size;
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
if (activity < BackendActivityBuffer ||
activity > activity_last)
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
return NULL;
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
/* If no string available, no point in a report */
if (activity[0] == '\0')
return NULL;
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
/*
* Copy only ASCII-safe characters so we don't run into encoding
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* problems when reporting the message; and be sure not to run off
* the end of memory.
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
*/
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
ascii_safe_strlcpy(buffer, activity,
Min(buflen, pgstat_track_activity_query_size));
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
return buffer;
}
beentry++;
}
/* PID not found */
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
return NULL;
Try to log current the query string when a backend crashes. To avoid minimize risk inside the postmaster, we subject this feature to a number of significant limitations. We very much wish to avoid doing any complex processing inside the postmaster, due to the posssibility that the crashed backend has completely corrupted shared memory. To that end, no encoding conversion is done; instead, we just replace anything that doesn't look like an ASCII character with a question mark. We limit the amount of data copied to 1024 characters, and carefully sanity check the source of that data. While these restrictions would doubtless be unacceptable in a general-purpose logging facility, even this limited facility seems like an improvement over the status quo ante. Marti Raudsepp, reviewed by PDXPUG and myself
2011-10-21 19:26:40 +02:00
}
Report the current queries of all backends involved in a deadlock (if they'd be visible to the current user in pg_stat_activity). This might look like it's subject to race conditions, but it's actually pretty safe because at the time DeadLockReport() is constructing the report, we haven't yet aborted our transaction and so we can expect that everyone else involved in the deadlock is still blocked on some lock. (There are corner cases where that might not be true, such as a statement timeout triggering in another backend before we finish reporting; but at worst we'd report a misleading activity string, so it seems acceptable considering the usefulness of reporting the queries.) Original patch by Itagaki Takahiro, heavily modified by me.
2008-03-21 22:08:31 +01:00
Code review for pgstat_get_crashed_backend_activity patch. Avoid possibly dumping core when pgstat_track_activity_query_size has a less-than-default value; avoid uselessly searching for the query string of a successfully-exited backend; don't bother putting out an ERRDETAIL if we don't have a query to show; some other minor stylistic improvements.
2011-10-21 22:36:04 +02:00
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/* ------------------------------------------------------------
* Local support functions follow
* ------------------------------------------------------------
*/
/* ----------
* pgstat_setheader() -
*
* Set common header fields in a statistics message
* ----------
*/
static void
pgstat_setheader(PgStat_MsgHdr *hdr, StatMsgType mtype)
{
hdr->m_type = mtype;
}
/* ----------
* pgstat_send() -
*
* Send out one statistics message to the collector
* ----------
*/
static void
pgstat_send(void *msg, int len)
{
Ensure that we retry rather than erroring out when send() or recv() return EINTR; the stats code was failing to do this and so were a couple of places in the postmaster. The stats code assumed that recv() could not return EINTR if a preceding select() showed the socket to be read-ready, but this is demonstrably false with our Windows implementation of recv(), and it may not be the case on all Unix variants either. I think this explains the intermittent stats regression test failures we've been seeing, as well as reports of stats collector instability under high load on Windows. Backpatch as far as 8.0.
2006-07-16 20:17:14 +02:00
int rc;
Make checks for invalid pgStatSock use PGINVALID_SOCKET
2010-01-31 18:39:34 +01:00
if (pgStatSock == PGINVALID_SOCKET)
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
return;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
((PgStat_MsgHdr *) msg)->m_size = len;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Ensure that we retry rather than erroring out when send() or recv() return EINTR; the stats code was failing to do this and so were a couple of places in the postmaster. The stats code assumed that recv() could not return EINTR if a preceding select() showed the socket to be read-ready, but this is demonstrably false with our Windows implementation of recv(), and it may not be the case on all Unix variants either. I think this explains the intermittent stats regression test failures we've been seeing, as well as reports of stats collector instability under high load on Windows. Backpatch as far as 8.0.
2006-07-16 20:17:14 +02:00
/* We'll retry after EINTR, but ignore all other failures */
do
{
rc = send(pgStatSock, msg, len, 0);
} while (rc < 0 && errno == EINTR);
Log send() failures when sending to statistics process (but only in assert-enabled builds). This is a temporary measure to see if we can learn anything about those intermittent stats test failures in the buildfarm.
2005-08-30 04:47:37 +02:00
#ifdef USE_ASSERT_CHECKING
Ensure that we retry rather than erroring out when send() or recv() return EINTR; the stats code was failing to do this and so were a couple of places in the postmaster. The stats code assumed that recv() could not return EINTR if a preceding select() showed the socket to be read-ready, but this is demonstrably false with our Windows implementation of recv(), and it may not be the case on all Unix variants either. I think this explains the intermittent stats regression test failures we've been seeing, as well as reports of stats collector instability under high load on Windows. Backpatch as far as 8.0.
2006-07-16 20:17:14 +02:00
/* In debug builds, log send failures ... */
if (rc < 0)
Log send() failures when sending to statistics process (but only in assert-enabled builds). This is a temporary measure to see if we can learn anything about those intermittent stats test failures in the buildfarm.
2005-08-30 04:47:37 +02:00
elog(LOG, "could not send to statistics collector: %m");
#endif
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
/* ----------
* pgstat_send_archiver() -
*
* Tell the collector about the WAL file that we successfully
* archived or failed to archive.
* ----------
*/
void
pgstat_send_archiver(const char *xlog, bool failed)
{
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
PgStat_MsgArchiver msg;
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
/*
* Prepare and send the message
*/
pgstat_setheader(&msg.m_hdr, PGSTAT_MTYPE_ARCHIVER);
msg.m_failed = failed;
Replace a bunch more uses of strncpy() with safer coding. strncpy() has a well-deserved reputation for being unsafe, so make an effort to get rid of nearly all occurrences in HEAD. A large fraction of the remaining uses were passing length less than or equal to the known strlen() of the source, in which case no null-padding can occur and the behavior is equivalent to memcpy(), though doubtless slower and certainly harder to reason about. So just use memcpy() in these cases. In other cases, use either StrNCpy() or strlcpy() as appropriate (depending on whether padding to the full length of the destination buffer seems useful). I left a few strncpy() calls alone in the src/timezone/ code, to keep it in sync with upstream (the IANA tzcode distribution). There are also a few such calls in ecpg that could possibly do with more analysis. AFAICT, none of these changes are more than cosmetic, except for the four occurrences in fe-secure-openssl.c, which are in fact buggy: an overlength source leads to a non-null-terminated destination buffer and ensuing misbehavior. These don't seem like security issues, first because no stack clobber is possible and second because if your values of sslcert etc are coming from untrusted sources then you've got problems way worse than this. Still, it's undesirable to have unpredictable behavior for overlength inputs, so back-patch those four changes to all active branches.
2015-01-24 19:05:42 +01:00
StrNCpy(msg.m_xlog, xlog, sizeof(msg.m_xlog));
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
msg.m_timestamp = GetCurrentTimestamp();
pgstat_send(&msg, sizeof(msg));
}
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
/* ----------
* pgstat_send_bgwriter() -
*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* Send bgwriter statistics to the collector
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
* ----------
*/
void
pgstat_send_bgwriter(void)
{
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
/* We assume this initializes to zeroes */
static const PgStat_MsgBgWriter all_zeroes;
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
/*
pgindent run for 8.3.
2007-11-15 22:14:46 +01:00
* This function can be called even if nothing at all has happened. In
* this case, avoid sending a completely empty message to the stats
* collector.
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
*/
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
if (memcmp(&BgWriterStats, &all_zeroes, sizeof(PgStat_MsgBgWriter)) == 0)
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
return;
/*
* Prepare and send the message
*/
pgstat_setheader(&BgWriterStats.m_hdr, PGSTAT_MTYPE_BGWRITER);
pgstat_send(&BgWriterStats, sizeof(BgWriterStats));
/*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* Clear out the statistics buffer, so it can be re-used.
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
*/
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
MemSet(&BgWriterStats, 0, sizeof(BgWriterStats));
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
/* ----------
* PgstatCollectorMain() -
*
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* Start up the statistics collector process. This is the body of the
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
* postmaster child process.
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
*
* The argc/argv parameters are valid only in EXEC_BACKEND case.
* ----------
*/
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
NON_EXEC_STATIC void
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
PgstatCollectorMain(int argc, char *argv[])
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
{
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
int len;
Continued rearrangement to permit pgstat + BootstrapMain processes to be fork/exec'd, in the same mode as the previous patch for backends. Claudio Natoli
2003-12-25 04:52:51 +01:00
PgStat_Msg msg;
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
int wr;
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
/*
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
* Ignore all signals usually bound to some action in the postmaster,
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
* except SIGHUP and SIGQUIT. Note we don't need a SIGUSR1 handler to
Add a default local latch for use in signal handlers. To do so, move InitializeLatchSupport() into the new common process initialization functions, and add a new global variable MyLatch. MyLatch is usable as soon InitPostmasterChild() has been called (i.e. very early during startup). Initially it points to a process local latch that exists in all processes. InitProcess/InitAuxiliaryProcess then replaces that local latch with PGPROC->procLatch. During shutdown the reverse happens. This is primarily advantageous for two reasons: For one it simplifies dealing with the shared process latch, especially in signal handlers, because instead of having to check for MyProc, MyLatch can be used unconditionally. For another, a later patch that makes FEs/BE communication use latches, now can rely on the existence of a latch, even before having gone through InitProcess. Discussion: 20140927191243.GD5423@alap3.anarazel.de
2015-01-14 18:45:22 +01:00
* support latch operations, because we only use a local latch.
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
*/
Make stats_temp_directory PGC_SIGHUP, and document how it may cause a temporary "outage" of the statistics views. This requires making the stats collector respond to SIGHUP, like the other utility processes already did.
2008-08-25 17:11:01 +02:00
pqsignal(SIGHUP, pgstat_sighup_handler);
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
pqsignal(SIGINT, SIG_IGN);
pqsignal(SIGTERM, SIG_IGN);
Fix Win32 problems with signals and sockets, by making the forkexec code even uglier than it was already :-(. Also, on Windows only, use temporary shared memory segments instead of ordinary files to pass over critical variable values from postmaster to child processes. Magnus Hagander
2004-11-17 01:14:14 +01:00
pqsignal(SIGQUIT, pgstat_exit);
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
pqsignal(SIGALRM, SIG_IGN);
Code review for EXEC_BACKEND changes. Reduce the number of #ifdefs by about a third, make it work on non-Windows platforms again. (But perhaps I broke the WIN32 code, since I have no way to test that.) Fold all the paths that fork postmaster child processes to go through the single routine SubPostmasterMain, which takes care of resurrecting the state that would normally be inherited from the postmaster (including GUC variables). Clean up some places where there's no particularly good reason for the EXEC and non-EXEC cases to work differently. Take care of one or two FIXMEs that remained in the code.
2004-05-28 07:13:32 +02:00
pqsignal(SIGPIPE, SIG_IGN);
pqsignal(SIGUSR1, SIG_IGN);
pqsignal(SIGUSR2, SIG_IGN);
pqsignal(SIGCHLD, SIG_DFL);
pqsignal(SIGTTIN, SIG_DFL);
pqsignal(SIGTTOU, SIG_DFL);
pqsignal(SIGCONT, SIG_DFL);
pqsignal(SIGWINCH, SIG_DFL);
PG_SETMASK(&UnBlockSig);
Fix handling of SIGCHLD, per recent pghackers discussion: on some platforms system(2) gets confused unless the signal handler is set to SIG_DFL, not SIG_IGN. pgstats.c now uses pqsignal() as it should, not signal(). Also, arrange for the stats collector process to show a reasonable ID in 'ps', rather than looking like a postmaster.
2001-08-04 02:14:43 +02:00
/*
* Identify myself via ps
*/
Add GUC update_process_title to control whether 'ps' display is updated for every command, default to on.
2006-06-28 00:16:44 +02:00
init_ps_display("stats collector process", "", "", "");
Fix handling of SIGCHLD, per recent pghackers discussion: on some platforms system(2) gets confused unless the signal handler is set to SIG_DFL, not SIG_IGN. pgstats.c now uses pqsignal() as it should, not signal(). Also, arrange for the stats collector process to show a reasonable ID in 'ps', rather than looking like a postmaster.
2001-08-04 02:14:43 +02:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* Read in an existing statistics stats file or initialize the stats to
* zero.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Use setitimer() for stats file write, rather than do a gettimeofday() call for every stats packet read to adjust select() timeout. Other stylistic improvements.
2006-01-03 17:42:17 +01:00
pgStatRunningInCollector = true;
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgStatDBHash = pgstat_read_statsfiles(InvalidOid, true, true);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
* Loop to process messages until we get SIGQUIT or detect ungraceful
* death of our parent postmaster.
*
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
* For performance reasons, we don't want to do ResetLatch/WaitLatch after
* every message; instead, do that only after a recv() fails to obtain a
* message. (This effectively means that if backends are sending us stuff
* like mad, we won't notice postmaster death until things slack off a
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
* bit; which seems fine.) To do that, we have an inner loop that
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
* iterates as long as recv() succeeds. We do recognize got_SIGHUP inside
* the inner loop, which means that such interrupts will get serviced but
* the latch won't get cleared until next time there is a break in the
* action.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
for (;;)
{
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
/* Clear any already-pending wakeups */
Add a default local latch for use in signal handlers. To do so, move InitializeLatchSupport() into the new common process initialization functions, and add a new global variable MyLatch. MyLatch is usable as soon InitPostmasterChild() has been called (i.e. very early during startup). Initially it points to a process local latch that exists in all processes. InitProcess/InitAuxiliaryProcess then replaces that local latch with PGPROC->procLatch. During shutdown the reverse happens. This is primarily advantageous for two reasons: For one it simplifies dealing with the shared process latch, especially in signal handlers, because instead of having to check for MyProc, MyLatch can be used unconditionally. For another, a later patch that makes FEs/BE communication use latches, now can rely on the existence of a latch, even before having gone through InitProcess. Discussion: 20140927191243.GD5423@alap3.anarazel.de
2015-01-14 18:45:22 +01:00
ResetLatch(MyLatch);
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
/*
* Quit if we get SIGQUIT from the postmaster.
*/
if (need_exit)
break;
Make stats_temp_directory PGC_SIGHUP, and document how it may cause a temporary "outage" of the statistics views. This requires making the stats collector respond to SIGHUP, like the other utility processes already did.
2008-08-25 17:11:01 +02:00
/*
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
* Inner loop iterates as long as we keep getting messages, or until
* need_exit becomes set.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
while (!need_exit)
Temporarily revert stats collector latch changes so we can ship beta1. This patch reverts commit 49340037ee3ab46cb24144a86705e35f272c24d5 and some follow-on tweaking in pgstat.c. While the basic scheme of latch-ifying the stats collector seems sound enough, it's failing on most Windows buildfarm members for unknown reasons, and there's no time left to debug that before 9.2beta1. Better to ship a beta version without this improvement. I hope to re-revert this once beta1 is out, though.
2012-05-10 23:26:08 +02:00
{
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
/*
* Reload configuration if we got SIGHUP from the postmaster.
*/
if (got_SIGHUP)
{
got_SIGHUP = false;
ProcessConfigFile(PGC_SIGHUP);
}
Temporarily revert stats collector latch changes so we can ship beta1. This patch reverts commit 49340037ee3ab46cb24144a86705e35f272c24d5 and some follow-on tweaking in pgstat.c. While the basic scheme of latch-ifying the stats collector seems sound enough, it's failing on most Windows buildfarm members for unknown reasons, and there's no time left to debug that before 9.2beta1. Better to ship a beta version without this improvement. I hope to re-revert this once beta1 is out, though.
2012-05-10 23:26:08 +02:00
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
/*
* Write the stats file if a new request has arrived that is not
* satisfied by existing file.
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
if (pgstat_write_statsfile_needed())
pgstat_write_statsfiles(false, false);
Temporarily revert stats collector latch changes so we can ship beta1. This patch reverts commit 49340037ee3ab46cb24144a86705e35f272c24d5 and some follow-on tweaking in pgstat.c. While the basic scheme of latch-ifying the stats collector seems sound enough, it's failing on most Windows buildfarm members for unknown reasons, and there's no time left to debug that before 9.2beta1. Better to ship a beta version without this improvement. I hope to re-revert this once beta1 is out, though.
2012-05-10 23:26:08 +02:00
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
/*
* Try to receive and process a message. This will not block,
* since the socket is set to non-blocking mode.
Force pgwin32_recv into nonblock mode when called from pgstat.c. This should get rid of the usage of pgwin32_waitforsinglesocket entirely, and perhaps thereby remove the race condition that's evidently still present on some versions of Windows. The previous arrangement was a bit unsafe anyway, since waiting at the recv() would not allow pgstat to notice postmaster death.
2012-05-14 16:57:07 +02:00
*
In pgstat.c, use a timeout in WaitLatchOrSocket only on Windows. We have no need for a timeout here really, but some broken products from Redmond seem to lose FD_READ events occasionally, and waking up and retrying the recv() is the only known way to work around that. Perhaps somebody will be motivated to figure out a better answer here; but not I.
2012-05-15 05:51:34 +02:00
* XXX On Windows, we have to force pgwin32_recv to cooperate,
* despite the previous use of pg_set_noblock() on the socket.
Force pgwin32_recv into nonblock mode when called from pgstat.c. This should get rid of the usage of pgwin32_waitforsinglesocket entirely, and perhaps thereby remove the race condition that's evidently still present on some versions of Windows. The previous arrangement was a bit unsafe anyway, since waiting at the recv() would not allow pgstat to notice postmaster death.
2012-05-14 16:57:07 +02:00
* This is extremely broken and should be fixed someday.
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
*/
Force pgwin32_recv into nonblock mode when called from pgstat.c. This should get rid of the usage of pgwin32_waitforsinglesocket entirely, and perhaps thereby remove the race condition that's evidently still present on some versions of Windows. The previous arrangement was a bit unsafe anyway, since waiting at the recv() would not allow pgstat to notice postmaster death.
2012-05-14 16:57:07 +02:00
#ifdef WIN32
pgwin32_noblock = 1;
#endif
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
len = recv(pgStatSock, (char *) &msg,
sizeof(PgStat_Msg), 0);
Force pgwin32_recv into nonblock mode when called from pgstat.c. This should get rid of the usage of pgwin32_waitforsinglesocket entirely, and perhaps thereby remove the race condition that's evidently still present on some versions of Windows. The previous arrangement was a bit unsafe anyway, since waiting at the recv() would not allow pgstat to notice postmaster death.
2012-05-14 16:57:07 +02:00
#ifdef WIN32
pgwin32_noblock = 0;
#endif
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
if (len < 0)
Ensure that we retry rather than erroring out when send() or recv() return EINTR; the stats code was failing to do this and so were a couple of places in the postmaster. The stats code assumed that recv() could not return EINTR if a preceding select() showed the socket to be read-ready, but this is demonstrably false with our Windows implementation of recv(), and it may not be the case on all Unix variants either. I think this explains the intermittent stats regression test failures we've been seeing, as well as reports of stats collector instability under high load on Windows. Backpatch as far as 8.0.
2006-07-16 20:17:14 +02:00
{
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
if (errno == EAGAIN || errno == EWOULDBLOCK || errno == EINTR)
break; /* out of inner loop */
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
ereport(ERROR,
(errcode_for_socket_access(),
errmsg("could not read statistics message: %m")));
Ensure that we retry rather than erroring out when send() or recv() return EINTR; the stats code was failing to do this and so were a couple of places in the postmaster. The stats code assumed that recv() could not return EINTR if a preceding select() showed the socket to be read-ready, but this is demonstrably false with our Windows implementation of recv(), and it may not be the case on all Unix variants either. I think this explains the intermittent stats regression test failures we've been seeing, as well as reports of stats collector instability under high load on Windows. Backpatch as far as 8.0.
2006-07-16 20:17:14 +02:00
}
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
* We ignore messages that are smaller than our common header
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
if (len < sizeof(PgStat_MsgHdr))
continue;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Endeavor to make pgstats buffer process (a) safe and (b) useful. Make sure it exits immediately when collector process dies --- in old code, buffer process would hang around and compete with the new buffer process for packets. Make sure it doesn't block on writing the pipe when the collector falls more than a pipeload behind. Avoid leaking pgstats FDs into every backend.
2001-08-05 04:06:50 +02:00
/*
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
* The received length must match the length in the header
Endeavor to make pgstats buffer process (a) safe and (b) useful. Make sure it exits immediately when collector process dies --- in old code, buffer process would hang around and compete with the new buffer process for packets. Make sure it doesn't block on writing the pipe when the collector falls more than a pipeload behind. Avoid leaking pgstats FDs into every backend.
2001-08-05 04:06:50 +02:00
*/
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
if (msg.msg_hdr.m_size != len)
continue;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
* O.K. - we accept this message. Process it.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
switch (msg.msg_hdr.m_type)
{
case PGSTAT_MTYPE_DUMMY:
break;
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
case PGSTAT_MTYPE_INQUIRY:
pgstat_recv_inquiry((PgStat_MsgInquiry *) &msg, len);
break;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
case PGSTAT_MTYPE_TABSTAT:
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
pgstat_recv_tabstat((PgStat_MsgTabstat *) &msg, len);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
break;
case PGSTAT_MTYPE_TABPURGE:
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
pgstat_recv_tabpurge((PgStat_MsgTabpurge *) &msg, len);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
break;
case PGSTAT_MTYPE_DROPDB:
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
pgstat_recv_dropdb((PgStat_MsgDropdb *) &msg, len);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
break;
case PGSTAT_MTYPE_RESETCOUNTER:
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
pgstat_recv_resetcounter((PgStat_MsgResetcounter *) &msg,
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
len);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
break;
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
case PGSTAT_MTYPE_RESETSHAREDCOUNTER:
pgstat_recv_resetsharedcounter(
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
(PgStat_MsgResetsharedcounter *) &msg,
len);
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
break;
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
case PGSTAT_MTYPE_RESETSINGLECOUNTER:
pgstat_recv_resetsinglecounter(
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
(PgStat_MsgResetsinglecounter *) &msg,
len);
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
break;
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
case PGSTAT_MTYPE_AUTOVAC_START:
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
pgstat_recv_autovac((PgStat_MsgAutovacStart *) &msg, len);
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
break;
case PGSTAT_MTYPE_VACUUM:
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
pgstat_recv_vacuum((PgStat_MsgVacuum *) &msg, len);
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
break;
case PGSTAT_MTYPE_ANALYZE:
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
pgstat_recv_analyze((PgStat_MsgAnalyze *) &msg, len);
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
break;
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
case PGSTAT_MTYPE_ARCHIVER:
pgstat_recv_archiver((PgStat_MsgArchiver *) &msg, len);
break;
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
case PGSTAT_MTYPE_BGWRITER:
Re-run pgindent with updated list of typedefs. (Updated README should avoid this problem in the future.)
2007-11-15 23:25:18 +01:00
pgstat_recv_bgwriter((PgStat_MsgBgWriter *) &msg, len);
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
break;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
case PGSTAT_MTYPE_FUNCSTAT:
pgstat_recv_funcstat((PgStat_MsgFuncstat *) &msg, len);
break;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
case PGSTAT_MTYPE_FUNCPURGE:
pgstat_recv_funcpurge((PgStat_MsgFuncpurge *) &msg, len);
break;
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
case PGSTAT_MTYPE_RECOVERYCONFLICT:
pgstat_recv_recoveryconflict((PgStat_MsgRecoveryConflict *) &msg, len);
break;
Add deadlock counter to pg_stat_database Adds a counter that tracks number of deadlocks that occurred in each database to pg_stat_database. Magnus Hagander, reviewed by Jaime Casanova
2012-01-26 15:58:19 +01:00
case PGSTAT_MTYPE_DEADLOCK:
pgstat_recv_deadlock((PgStat_MsgDeadlock *) &msg, len);
break;
Track temporary file count and size in pg_stat_database Add counters for number and size of temporary files used for spill-to-disk queries for each database to the pg_stat_database view. Tomas Vondra, review by Magnus Hagander
2012-01-26 14:41:19 +01:00
case PGSTAT_MTYPE_TEMPFILE:
pgstat_recv_tempfile((PgStat_MsgTempFile *) &msg, len);
break;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
default:
break;
}
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
} /* end of inner message-processing loop */
/* Sleep until there's something to do */
In pgstat.c, use a timeout in WaitLatchOrSocket only on Windows. We have no need for a timeout here really, but some broken products from Redmond seem to lose FD_READ events occasionally, and waking up and retrying the recv() is the only known way to work around that. Perhaps somebody will be motivated to figure out a better answer here; but not I.
2012-05-15 05:51:34 +02:00
#ifndef WIN32
Add a default local latch for use in signal handlers. To do so, move InitializeLatchSupport() into the new common process initialization functions, and add a new global variable MyLatch. MyLatch is usable as soon InitPostmasterChild() has been called (i.e. very early during startup). Initially it points to a process local latch that exists in all processes. InitProcess/InitAuxiliaryProcess then replaces that local latch with PGPROC->procLatch. During shutdown the reverse happens. This is primarily advantageous for two reasons: For one it simplifies dealing with the shared process latch, especially in signal handlers, because instead of having to check for MyProc, MyLatch can be used unconditionally. For another, a later patch that makes FEs/BE communication use latches, now can rely on the existence of a latch, even before having gone through InitProcess. Discussion: 20140927191243.GD5423@alap3.anarazel.de
2015-01-14 18:45:22 +01:00
wr = WaitLatchOrSocket(MyLatch,
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
WL_LATCH_SET | WL_POSTMASTER_DEATH | WL_SOCKET_READABLE,
In pgstat.c, use a timeout in WaitLatchOrSocket only on Windows. We have no need for a timeout here really, but some broken products from Redmond seem to lose FD_READ events occasionally, and waking up and retrying the recv() is the only known way to work around that. Perhaps somebody will be motivated to figure out a better answer here; but not I.
2012-05-15 05:51:34 +02:00
pgStatSock,
-1L);
#else
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
In pgstat.c, use a timeout in WaitLatchOrSocket only on Windows. We have no need for a timeout here really, but some broken products from Redmond seem to lose FD_READ events occasionally, and waking up and retrying the recv() is the only known way to work around that. Perhaps somebody will be motivated to figure out a better answer here; but not I.
2012-05-15 05:51:34 +02:00
/*
* Windows, at least in its Windows Server 2003 R2 incarnation,
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* sometimes loses FD_READ events. Waking up and retrying the recv()
In pgstat.c, use a timeout in WaitLatchOrSocket only on Windows. We have no need for a timeout here really, but some broken products from Redmond seem to lose FD_READ events occasionally, and waking up and retrying the recv() is the only known way to work around that. Perhaps somebody will be motivated to figure out a better answer here; but not I.
2012-05-15 05:51:34 +02:00
* fixes that, so don't sleep indefinitely. This is a crock of the
* first water, but until somebody wants to debug exactly what's
* happening there, this is the best we can do. The two-second
* timeout matches our pre-9.2 behavior, and needs to be short enough
Adjust "pgstat wait timeout" message to be a translatable LOG message. Per discussion, change the log level of this message to be LOG not WARNING. The main point of this change is to avoid causing buildfarm run failures when the stats collector is exceptionally slow to respond, which it not infrequently is on some of the smaller/slower buildfarm members. This change does lose notice to an interactive user when his stats query is looking at out-of-date stats, but the majority opinion (not necessarily that of yours truly) is that WARNING messages would probably not get noticed anyway on heavily loaded production systems. A LOG message at least ensures that the problem is recorded somewhere where bulk auditing for the issue is possible. Also, instead of an untranslated "pgstat wait timeout" message, provide a translatable and hopefully more understandable message "using stale statistics instead of current ones because stats collector is not responding". The original text was written hastily under the assumption that it would never really happen in practice, which we now know to be unduly optimistic. Back-patch to all active branches, since we've seen the buildfarm issue in all branches.
2015-01-20 05:01:33 +01:00
* to not provoke "using stale statistics" complaints from
In pgstat.c, use a timeout in WaitLatchOrSocket only on Windows. We have no need for a timeout here really, but some broken products from Redmond seem to lose FD_READ events occasionally, and waking up and retrying the recv() is the only known way to work around that. Perhaps somebody will be motivated to figure out a better answer here; but not I.
2012-05-15 05:51:34 +02:00
* backend_read_statsfile.
*/
Add a default local latch for use in signal handlers. To do so, move InitializeLatchSupport() into the new common process initialization functions, and add a new global variable MyLatch. MyLatch is usable as soon InitPostmasterChild() has been called (i.e. very early during startup). Initially it points to a process local latch that exists in all processes. InitProcess/InitAuxiliaryProcess then replaces that local latch with PGPROC->procLatch. During shutdown the reverse happens. This is primarily advantageous for two reasons: For one it simplifies dealing with the shared process latch, especially in signal handlers, because instead of having to check for MyProc, MyLatch can be used unconditionally. For another, a later patch that makes FEs/BE communication use latches, now can rely on the existence of a latch, even before having gone through InitProcess. Discussion: 20140927191243.GD5423@alap3.anarazel.de
2015-01-14 18:45:22 +01:00
wr = WaitLatchOrSocket(MyLatch,
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
WL_LATCH_SET | WL_POSTMASTER_DEATH | WL_SOCKET_READABLE | WL_TIMEOUT,
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
pgStatSock,
Run pgindent on 9.2 source tree in preparation for first 9.3 commit-fest.
2012-06-10 21:20:04 +02:00
2 * 1000L /* msec */ );
In pgstat.c, use a timeout in WaitLatchOrSocket only on Windows. We have no need for a timeout here really, but some broken products from Redmond seem to lose FD_READ events occasionally, and waking up and retrying the recv() is the only known way to work around that. Perhaps somebody will be motivated to figure out a better answer here; but not I.
2012-05-15 05:51:34 +02:00
#endif
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
/*
* Emergency bailout if postmaster has died. This is to avoid the
* necessity for manual cleanup of all postmaster children.
*/
if (wr & WL_POSTMASTER_DEATH)
break;
} /* end of outer loop */
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
/*
* Save the final stats to reuse at next startup.
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgstat_write_statsfiles(true, true);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
exit(0);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
/* SIGQUIT signal handler for collector process */
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
static void
pgstat_exit(SIGNAL_ARGS)
{
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
int save_errno = errno;
Remove the separate 'stats buffer' process, letting backend stats messages be delivered directly to the collector process. The extra process context swaps required to transfer data through the buffer process seem to outweigh any value the buffering might have. Per recent discussion and tests. I modified Bruce's draft patch to use poll() rather than select() where available (this makes a noticeable difference on my system), and fixed up the EXEC_BACKEND case.
2006-06-29 22:00:08 +02:00
need_exit = true;
Add a default local latch for use in signal handlers. To do so, move InitializeLatchSupport() into the new common process initialization functions, and add a new global variable MyLatch. MyLatch is usable as soon InitPostmasterChild() has been called (i.e. very early during startup). Initially it points to a process local latch that exists in all processes. InitProcess/InitAuxiliaryProcess then replaces that local latch with PGPROC->procLatch. During shutdown the reverse happens. This is primarily advantageous for two reasons: For one it simplifies dealing with the shared process latch, especially in signal handlers, because instead of having to check for MyProc, MyLatch can be used unconditionally. For another, a later patch that makes FEs/BE communication use latches, now can rely on the existence of a latch, even before having gone through InitProcess. Discussion: 20140927191243.GD5423@alap3.anarazel.de
2015-01-14 18:45:22 +01:00
SetLatch(MyLatch);
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
errno = save_errno;
Arrange to explicitly stop the pgstat processes at the same time we begin the shutdown checkpoint; there isn't anything left for them to do, so we may as well ensure that they shut down sooner rather than later. Per discussion.
2004-06-14 20:08:19 +02:00
}
Make stats_temp_directory PGC_SIGHUP, and document how it may cause a temporary "outage" of the statistics views. This requires making the stats collector respond to SIGHUP, like the other utility processes already did.
2008-08-25 17:11:01 +02:00
/* SIGHUP handler for collector process */
static void
pgstat_sighup_handler(SIGNAL_ARGS)
{
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
int save_errno = errno;
Make stats_temp_directory PGC_SIGHUP, and document how it may cause a temporary "outage" of the statistics views. This requires making the stats collector respond to SIGHUP, like the other utility processes already did.
2008-08-25 17:11:01 +02:00
got_SIGHUP = true;
Add a default local latch for use in signal handlers. To do so, move InitializeLatchSupport() into the new common process initialization functions, and add a new global variable MyLatch. MyLatch is usable as soon InitPostmasterChild() has been called (i.e. very early during startup). Initially it points to a process local latch that exists in all processes. InitProcess/InitAuxiliaryProcess then replaces that local latch with PGPROC->procLatch. During shutdown the reverse happens. This is primarily advantageous for two reasons: For one it simplifies dealing with the shared process latch, especially in signal handlers, because instead of having to check for MyProc, MyLatch can be used unconditionally. For another, a later patch that makes FEs/BE communication use latches, now can rely on the existence of a latch, even before having gone through InitProcess. Discussion: 20140927191243.GD5423@alap3.anarazel.de
2015-01-14 18:45:22 +01:00
SetLatch(MyLatch);
Re-revert stats collector latch changes. This reverts commit cb2f2873d6b81ad7f0a9733ba738bfac0746fb7b, restoring the latch-ified stats collector logic. We'll soon see if this works any better on the Windows buildfarm machines.
2012-05-13 20:44:39 +02:00
errno = save_errno;
Make stats_temp_directory PGC_SIGHUP, and document how it may cause a temporary "outage" of the statistics views. This requires making the stats collector respond to SIGHUP, like the other utility processes already did.
2008-08-25 17:11:01 +02:00
}
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/*
* Subroutine to clear stats in a database entry
*
* Tables and functions hashes are initialized to empty.
*/
static void
reset_dbentry_counters(PgStat_StatDBEntry *dbentry)
{
HASHCTL hash_ctl;
dbentry->n_xact_commit = 0;
dbentry->n_xact_rollback = 0;
dbentry->n_blocks_fetched = 0;
dbentry->n_blocks_hit = 0;
dbentry->n_tuples_returned = 0;
dbentry->n_tuples_fetched = 0;
dbentry->n_tuples_inserted = 0;
dbentry->n_tuples_updated = 0;
dbentry->n_tuples_deleted = 0;
dbentry->last_autovac_time = 0;
dbentry->n_conflict_tablespace = 0;
dbentry->n_conflict_lock = 0;
dbentry->n_conflict_snapshot = 0;
dbentry->n_conflict_bufferpin = 0;
dbentry->n_conflict_startup_deadlock = 0;
dbentry->n_temp_files = 0;
dbentry->n_temp_bytes = 0;
dbentry->n_deadlocks = 0;
dbentry->n_block_read_time = 0;
dbentry->n_block_write_time = 0;
dbentry->stat_reset_timestamp = GetCurrentTimestamp();
dbentry->stats_timestamp = 0;
memset(&hash_ctl, 0, sizeof(hash_ctl));
hash_ctl.keysize = sizeof(Oid);
hash_ctl.entrysize = sizeof(PgStat_StatTabEntry);
dbentry->tables = hash_create("Per-database table",
PGSTAT_TAB_HASH_SIZE,
&hash_ctl,
Improve hash_create's API for selecting simple-binary-key hash functions. Previously, if you wanted anything besides C-string hash keys, you had to specify a custom hashing function to hash_create(). Nearly all such callers were specifying tag_hash or oid_hash; which is tedious, and rather error-prone, since a caller could easily miss the opportunity to optimize by using hash_uint32 when appropriate. Replace this with a design whereby callers using simple binary-data keys just specify HASH_BLOBS and don't need to mess with specific support functions. hash_create() itself will take care of optimizing when the key size is four bytes. This nets out saving a few hundred bytes of code space, and offers a measurable performance improvement in tidbitmap.c (which was not exploiting the opportunity to use hash_uint32 for its 4-byte keys). There might be some wins elsewhere too, I didn't analyze closely. In future we could look into offering a similar optimized hashing function for 8-byte keys. Under this design that could be done in a centralized and machine-independent fashion, whereas getting it right for keys of platform-dependent sizes would've been notationally painful before. For the moment, the old way still works fine, so as not to break source code compatibility for loadable modules. Eventually we might want to remove tag_hash and friends from the exported API altogether, since there's no real need for them to be explicitly referenced from outside dynahash.c. Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
HASH_ELEM | HASH_BLOBS);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
hash_ctl.keysize = sizeof(Oid);
hash_ctl.entrysize = sizeof(PgStat_StatFuncEntry);
dbentry->functions = hash_create("Per-database function",
PGSTAT_FUNCTION_HASH_SIZE,
&hash_ctl,
Improve hash_create's API for selecting simple-binary-key hash functions. Previously, if you wanted anything besides C-string hash keys, you had to specify a custom hashing function to hash_create(). Nearly all such callers were specifying tag_hash or oid_hash; which is tedious, and rather error-prone, since a caller could easily miss the opportunity to optimize by using hash_uint32 when appropriate. Replace this with a design whereby callers using simple binary-data keys just specify HASH_BLOBS and don't need to mess with specific support functions. hash_create() itself will take care of optimizing when the key size is four bytes. This nets out saving a few hundred bytes of code space, and offers a measurable performance improvement in tidbitmap.c (which was not exploiting the opportunity to use hash_uint32 for its 4-byte keys). There might be some wins elsewhere too, I didn't analyze closely. In future we could look into offering a similar optimized hashing function for 8-byte keys. Under this design that could be done in a centralized and machine-independent fashion, whereas getting it right for keys of platform-dependent sizes would've been notationally painful before. For the moment, the old way still works fine, so as not to break source code compatibility for loadable modules. Eventually we might want to remove tag_hash and friends from the exported API altogether, since there's no real need for them to be explicitly referenced from outside dynahash.c. Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
HASH_ELEM | HASH_BLOBS);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
/*
* Lookup the hash table entry for the specified database. If no hash
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
* table entry exists, initialize it, if the create parameter is true.
* Else, return NULL.
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
*/
static PgStat_StatDBEntry *
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
pgstat_get_db_entry(Oid databaseid, bool create)
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
{
PgStat_StatDBEntry *result;
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
bool found;
HASHACTION action = (create ? HASH_ENTER : HASH_FIND);
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
/* Lookup or create the hash table entry for this database */
result = (PgStat_StatDBEntry *) hash_search(pgStatDBHash,
&databaseid,
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
action, &found);
if (!create && !found)
return NULL;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/*
* If not found, initialize the new one. This creates empty hash tables
* for tables and functions, too.
*/
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
if (!found)
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
reset_dbentry_counters(result);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
return result;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
/*
* Lookup the hash table entry for the specified table. If no hash
* table entry exists, initialize it, if the create parameter is true.
* Else, return NULL.
*/
static PgStat_StatTabEntry *
pgstat_get_tab_entry(PgStat_StatDBEntry *dbentry, Oid tableoid, bool create)
{
PgStat_StatTabEntry *result;
bool found;
HASHACTION action = (create ? HASH_ENTER : HASH_FIND);
/* Lookup or create the hash table entry for this table */
result = (PgStat_StatTabEntry *) hash_search(dbentry->tables,
&tableoid,
action, &found);
if (!create && !found)
return NULL;
/* If not found, initialize the new one. */
if (!found)
{
result->numscans = 0;
result->tuples_returned = 0;
result->tuples_fetched = 0;
result->tuples_inserted = 0;
result->tuples_updated = 0;
result->tuples_deleted = 0;
result->tuples_hot_updated = 0;
result->n_live_tuples = 0;
result->n_dead_tuples = 0;
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
result->changes_since_analyze = 0;
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
result->blocks_fetched = 0;
result->blocks_hit = 0;
result->vacuum_timestamp = 0;
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
result->vacuum_count = 0;
Zero out vacuum_count and related counters in pgstat_recv_tabstat(). This fixes an oversight in commit 946045f04d11d246a834b917a2b8bc6e4f884a37 of 2010-08-21, as reported by Itagaki Takahiro. Also a couple of minor cosmetic adjustments.
2011-03-07 17:17:06 +01:00
result->autovac_vacuum_timestamp = 0;
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
result->autovac_vacuum_count = 0;
Zero out vacuum_count and related counters in pgstat_recv_tabstat(). This fixes an oversight in commit 946045f04d11d246a834b917a2b8bc6e4f884a37 of 2010-08-21, as reported by Itagaki Takahiro. Also a couple of minor cosmetic adjustments.
2011-03-07 17:17:06 +01:00
result->analyze_timestamp = 0;
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
result->analyze_count = 0;
Zero out vacuum_count and related counters in pgstat_recv_tabstat(). This fixes an oversight in commit 946045f04d11d246a834b917a2b8bc6e4f884a37 of 2010-08-21, as reported by Itagaki Takahiro. Also a couple of minor cosmetic adjustments.
2011-03-07 17:17:06 +01:00
result->autovac_analyze_timestamp = 0;
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
result->autovac_analyze_count = 0;
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
}
return result;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* pgstat_write_statsfiles() -
* Write the global statistics file, as well as requested DB files.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* If writing to the permanent files (happens when the collector is
* shutting down only), remove the temporary files so that backends
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
* starting up under a new postmaster can't read the old data before
* the new collector is ready.
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
*
* When 'allDbs' is false, only the requested databases (listed in
* last_statrequests) will be written; otherwise, all databases will be
* written.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
static void
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgstat_write_statsfiles(bool permanent, bool allDbs)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
HASH_SEQ_STATUS hstat;
PgStat_StatDBEntry *dbentry;
FILE *fpout;
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
int32 format_id;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
const char *tmpfile = permanent ? PGSTAT_STAT_PERMANENT_TMPFILE : pgstat_stat_tmpname;
const char *statfile = permanent ? PGSTAT_STAT_PERMANENT_FILENAME : pgstat_stat_filename;
Suppress -Wunused-result warnings about write() and fwrite(). This is merely an exercise in satisfying pedants, not a bug fix, because in every case we were checking for failure later with ferror(), or else there was nothing useful to be done about a failure anyway. Document the latter cases.
2011-10-19 03:37:51 +02:00
int rc;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Fix assorted confusion between Oid and int32. In passing, also make some debugging elog's in pgstat.c a bit more consistently worded. Back-patch as far as applicable (9.3 or 9.4; none of these mistakes are really old). Mark Dilger identified and patched the type violations; the message rewordings are mine.
2014-12-11 21:41:15 +01:00
elog(DEBUG2, "writing stats file \"%s\"", statfile);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
* Open the statistics temp file to write out the current values.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
fpout = AllocateFile(tmpfile, PG_BINARY_W);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
if (fpout == NULL)
{
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
ereport(LOG,
(errcode_for_file_access(),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("could not open temporary statistics file \"%s\": %m",
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
tmpfile)));
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
return;
}
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
/*
* Set the timestamp of the stats file.
*/
globalStats.stats_timestamp = GetCurrentTimestamp();
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
/*
* Write the file header --- currently just a format ID.
*/
format_id = PGSTAT_FILE_FORMAT_ID;
Suppress -Wunused-result warnings about write() and fwrite(). This is merely an exercise in satisfying pedants, not a bug fix, because in every case we were checking for failure later with ferror(), or else there was nothing useful to be done about a failure anyway. Document the latter cases.
2011-10-19 03:37:51 +02:00
rc = fwrite(&format_id, sizeof(format_id), 1, fpout);
(void) rc; /* we'll check for error with ferror */
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
/*
* Write global stats struct
*/
Suppress -Wunused-result warnings about write() and fwrite(). This is merely an exercise in satisfying pedants, not a bug fix, because in every case we were checking for failure later with ferror(), or else there was nothing useful to be done about a failure anyway. Document the latter cases.
2011-10-19 03:37:51 +02:00
rc = fwrite(&globalStats, sizeof(globalStats), 1, fpout);
(void) rc; /* we'll check for error with ferror */
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
/*
* Write archiver stats struct
*/
rc = fwrite(&archiverStats, sizeof(archiverStats), 1, fpout);
(void) rc; /* we'll check for error with ferror */
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
* Walk through the database table.
*/
hash_seq_init(&hstat, pgStatDBHash);
Further cleanup of dynahash.c API, in pursuit of portability and readability. Bizarre '(long *) TRUE' return convention is gone, in favor of just raising an error internally in dynahash.c when we detect hashtable corruption. HashTableWalk is gone, in favor of using hash_seq_search directly, since it had no hope of working with non-LONGALIGNable datatypes. Simplify some other code that was made undesirably grotty by promixity to HashTableWalk.
2001-10-05 19:28:13 +02:00
while ((dbentry = (PgStat_StatDBEntry *) hash_seq_search(&hstat)) != NULL)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
/*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* Write out the tables and functions into the DB stat file, if
* required.
*
* We need to do this before the dbentry write, to ensure the
* timestamps written to both are consistent.
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
if (allDbs || pgstat_db_requested(dbentry->databaseid))
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
{
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
dbentry->stats_timestamp = globalStats.stats_timestamp;
pgstat_write_db_statsfile(dbentry, permanent);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* Write out the DB entry. We don't write the tables or functions
* pointers, since they're of no use to any other process.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
fputc('D', fpout);
rc = fwrite(dbentry, offsetof(PgStat_StatDBEntry, tables), 1, fpout);
(void) rc; /* we'll check for error with ferror */
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
/*
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
* No more output to be done. Close the temp file and replace the old
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
* pgstat.stat with it. The ferror() check replaces testing for error
* after each individual fputc or fwrite above.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
fputc('E', fpout);
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
if (ferror(fpout))
{
ereport(LOG,
(errcode_for_file_access(),
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
errmsg("could not write temporary statistics file \"%s\": %m",
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
tmpfile)));
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
FreeFile(fpout);
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
unlink(tmpfile);
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
}
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
else if (FreeFile(fpout) < 0)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
ereport(LOG,
(errcode_for_file_access(),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
errmsg("could not close temporary statistics file \"%s\": %m",
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
tmpfile)));
unlink(tmpfile);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
else if (rename(tmpfile, statfile) < 0)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not rename temporary statistics file \"%s\" to \"%s\": %m",
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
tmpfile, statfile)));
unlink(tmpfile);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
if (permanent)
unlink(pgstat_stat_filename);
/*
* Now throw away the list of requests. Note that requests sent after we
* started the write are still waiting on the network socket.
*/
if (!slist_is_empty(&last_statrequests))
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
{
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
slist_mutable_iter iter;
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
Improve ilist.h's support for deletion of slist elements during iteration. Previously one had to use slist_delete(), implying an additional scan of the list, making this infrastructure considerably less efficient than traditional Lists when deletion of element(s) in a long list is needed. Modify the slist_foreach_modify() macro to support deleting the current element in O(1) time, by keeping a "prev" pointer in addition to "cur" and "next". Although this makes iteration with this macro a bit slower, no real harm is done, since in any scenario where you're not going to delete the current list element you might as well just use slist_foreach instead. Improve the comments about when to use each macro. Back-patch to 9.3 so that we'll have consistent semantics in all branches that provide ilist.h. Note this is an ABI break for callers of slist_foreach_modify(). Andres Freund and Tom Lane
2013-07-24 23:41:55 +02:00
/*
* Strictly speaking we should do slist_delete_current() before
* freeing each request struct. We skip that and instead
* re-initialize the list header at the end. Nonetheless, we must use
* slist_foreach_modify, not just slist_foreach, since we will free
* the node's storage before advancing.
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
slist_foreach_modify(iter, &last_statrequests)
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
{
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
DBWriteRequest *req;
Now that we know last_statrequest > last_statwrite can be observed in the buildfarm, expend a little more effort on the log message for it.
2010-03-24 17:07:10 +01:00
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
req = slist_container(DBWriteRequest, next, iter.cur);
pfree(req);
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
}
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
slist_init(&last_statrequests);
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
}
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
}
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/*
* return the filename for a DB stat file; filename is the output buffer,
* of length len.
*/
static void
get_dbstat_filename(bool permanent, bool tempname, Oid databaseid,
char *filename, int len)
{
int printed;
Fix removal of files in pgstats directories Instead of deleting all files in stats_temp_directory and the permanent directory on a crash, only remove those files that match the pattern of files we actually write in them, to avoid possibly clobbering existing unrelated contents of the temporary directory. Per complaint from Jeff Janes, and subsequent discussion, starting at message CAMkU=1z9+7RsDODnT4=cDFBRBp8wYQbd_qsLcMtKEf-oFwuOdQ@mail.gmail.com Also, fix a bug in the same routine to avoid removing files from the permanent directory twice (instead of once from that directory and then from the temporary directory), also per report from Jeff Janes, in message CAMkU=1wbk947=-pAosDMX5VC+sQw9W4ttq6RM9rXu=MjNeEQKA@mail.gmail.com
2013-08-19 23:48:17 +02:00
/* NB -- pgstat_reset_remove_files knows about the pattern this uses */
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
printed = snprintf(filename, len, "%s/db_%u.%s",
permanent ? PGSTAT_STAT_PERMANENT_DIRECTORY :
pgstat_stat_directory,
databaseid,
tempname ? "tmp" : "stat");
if (printed > len)
elog(ERROR, "overlength pgstat path");
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/* ----------
* pgstat_write_db_statsfile() -
* Write the stat file for a single database.
*
* If writing to the permanent file (happens when the collector is
* shutting down only), remove the temporary file so that backends
* starting up under a new postmaster can't read the old data before
* the new collector is ready.
* ----------
*/
static void
pgstat_write_db_statsfile(PgStat_StatDBEntry *dbentry, bool permanent)
{
HASH_SEQ_STATUS tstat;
HASH_SEQ_STATUS fstat;
PgStat_StatTabEntry *tabentry;
PgStat_StatFuncEntry *funcentry;
FILE *fpout;
int32 format_id;
Oid dbid = dbentry->databaseid;
int rc;
char tmpfile[MAXPGPATH];
char statfile[MAXPGPATH];
get_dbstat_filename(permanent, true, dbid, tmpfile, MAXPGPATH);
get_dbstat_filename(permanent, false, dbid, statfile, MAXPGPATH);
Fix assorted confusion between Oid and int32. In passing, also make some debugging elog's in pgstat.c a bit more consistently worded. Back-patch as far as applicable (9.3 or 9.4; none of these mistakes are really old). Mark Dilger identified and patched the type violations; the message rewordings are mine.
2014-12-11 21:41:15 +01:00
elog(DEBUG2, "writing stats file \"%s\"", statfile);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/*
* Open the statistics temp file to write out the current values.
*/
fpout = AllocateFile(tmpfile, PG_BINARY_W);
if (fpout == NULL)
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not open temporary statistics file \"%s\": %m",
tmpfile)));
return;
}
/*
* Write the file header --- currently just a format ID.
*/
format_id = PGSTAT_FILE_FORMAT_ID;
rc = fwrite(&format_id, sizeof(format_id), 1, fpout);
(void) rc; /* we'll check for error with ferror */
/*
* Walk through the database's access stats per table.
*/
hash_seq_init(&tstat, dbentry->tables);
while ((tabentry = (PgStat_StatTabEntry *) hash_seq_search(&tstat)) != NULL)
{
fputc('T', fpout);
rc = fwrite(tabentry, sizeof(PgStat_StatTabEntry), 1, fpout);
(void) rc; /* we'll check for error with ferror */
}
/*
* Walk through the database's function stats table.
*/
hash_seq_init(&fstat, dbentry->functions);
while ((funcentry = (PgStat_StatFuncEntry *) hash_seq_search(&fstat)) != NULL)
{
fputc('F', fpout);
rc = fwrite(funcentry, sizeof(PgStat_StatFuncEntry), 1, fpout);
(void) rc; /* we'll check for error with ferror */
}
/*
* No more output to be done. Close the temp file and replace the old
* pgstat.stat with it. The ferror() check replaces testing for error
* after each individual fputc or fwrite above.
*/
fputc('E', fpout);
if (ferror(fpout))
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not write temporary statistics file \"%s\": %m",
tmpfile)));
FreeFile(fpout);
unlink(tmpfile);
}
else if (FreeFile(fpout) < 0)
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not close temporary statistics file \"%s\": %m",
tmpfile)));
unlink(tmpfile);
}
else if (rename(tmpfile, statfile) < 0)
{
ereport(LOG,
(errcode_for_file_access(),
errmsg("could not rename temporary statistics file \"%s\" to \"%s\": %m",
tmpfile, statfile)));
unlink(tmpfile);
}
if (permanent)
{
get_dbstat_filename(false, false, dbid, statfile, MAXPGPATH);
Fix assorted confusion between Oid and int32. In passing, also make some debugging elog's in pgstat.c a bit more consistently worded. Back-patch as far as applicable (9.3 or 9.4; none of these mistakes are really old). Mark Dilger identified and patched the type violations; the message rewordings are mine.
2014-12-11 21:41:15 +01:00
elog(DEBUG2, "removing temporary stats file \"%s\"", statfile);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
unlink(statfile);
}
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* pgstat_read_statsfiles() -
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* Reads in the existing statistics collector files and initializes the
* databases' hash table. If the permanent file name is requested (which
* only happens in the stats collector itself), also remove the file after
* reading; the in-memory status is now authoritative, and the permanent file
* would be out of date in case somebody else reads it.
*
* If a deep read is requested, table/function stats are read also, otherwise
* the table/function hash tables remain empty.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
static HTAB *
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgstat_read_statsfiles(Oid onlydb, bool permanent, bool deep)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
PgStat_StatDBEntry *dbentry;
PgStat_StatDBEntry dbbuf;
HASHCTL hash_ctl;
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
HTAB *dbhash;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
FILE *fpin;
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
int32 format_id;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
bool found;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
const char *statfile = permanent ? PGSTAT_STAT_PERMANENT_FILENAME : pgstat_stat_filename;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
/*
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
* The tables will live in pgStatLocalContext.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
pgstat_setup_memcxt();
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
* Create the DB hashtable
*/
memset(&hash_ctl, 0, sizeof(hash_ctl));
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
hash_ctl.keysize = sizeof(Oid);
Another round of cleanups for dynahash.c (maybe it's finally clean of portability issues). Caller-visible data structures are now allocated on MAXALIGN boundaries, allowing safe use of datatypes wider than 'long'. Rejigger hash_create API so that caller specifies size of key and total size of entry, not size of key and size of rest of entry. This simplifies life considerably since each number is just a sizeof(), and padding issues etc. are taken care of automatically.
2001-10-01 07:36:17 +02:00
hash_ctl.entrysize = sizeof(PgStat_StatDBEntry);
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
hash_ctl.hcxt = pgStatLocalContext;
dbhash = hash_create("Databases hash", PGSTAT_DB_HASH_SIZE, &hash_ctl,
Improve hash_create's API for selecting simple-binary-key hash functions. Previously, if you wanted anything besides C-string hash keys, you had to specify a custom hashing function to hash_create(). Nearly all such callers were specifying tag_hash or oid_hash; which is tedious, and rather error-prone, since a caller could easily miss the opportunity to optimize by using hash_uint32 when appropriate. Replace this with a design whereby callers using simple binary-data keys just specify HASH_BLOBS and don't need to mess with specific support functions. hash_create() itself will take care of optimizing when the key size is four bytes. This nets out saving a few hundred bytes of code space, and offers a measurable performance improvement in tidbitmap.c (which was not exploiting the opportunity to use hash_uint32 for its 4-byte keys). There might be some wins elsewhere too, I didn't analyze closely. In future we could look into offering a similar optimized hashing function for 8-byte keys. Under this design that could be done in a centralized and machine-independent fashion, whereas getting it right for keys of platform-dependent sizes would've been notationally painful before. For the moment, the old way still works fine, so as not to break source code compatibility for loadable modules. Eventually we might want to remove tag_hash and friends from the exported API altogether, since there's no real need for them to be explicitly referenced from outside dynahash.c. Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
/*
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* Clear out global and archiver statistics so they start from zero in
* case we can't load an existing statsfile.
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
*/
memset(&globalStats, 0, sizeof(globalStats));
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
memset(&archiverStats, 0, sizeof(archiverStats));
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
Track last time for statistics reset on databases and bgwriter Tracks one counter for each database, which is reset whenever the statistics for any individual object inside the database is reset, and one counter for the background writer. Tomas Vondra, reviewed by Greg Smith
2011-02-10 15:09:35 +01:00
/*
* Set the current timestamp (will be kept only in case we can't load an
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
* existing statsfile).
Track last time for statistics reset on databases and bgwriter Tracks one counter for each database, which is reset whenever the statistics for any individual object inside the database is reset, and one counter for the background writer. Tomas Vondra, reviewed by Greg Smith
2011-02-10 15:09:35 +01:00
*/
globalStats.stat_reset_timestamp = GetCurrentTimestamp();
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
archiverStats.stat_reset_timestamp = globalStats.stat_reset_timestamp;
Track last time for statistics reset on databases and bgwriter Tracks one counter for each database, which is reset whenever the statistics for any individual object inside the database is reset, and one counter for the background writer. Tomas Vondra, reviewed by Greg Smith
2011-02-10 15:09:35 +01:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* Try to open the stats file. If it doesn't exist, the backends simply
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* return zero for anything and the collector simply starts from scratch
* with empty counters.
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
*
* ENOENT is a possibility if the stats collector is not running or has
* not yet written the stats file the first time. Any other failure
* condition is suspicious.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
if ((fpin = AllocateFile(statfile, PG_BINARY_R)) == NULL)
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
{
if (errno != ENOENT)
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errcode_for_file_access(),
errmsg("could not open statistics file \"%s\": %m",
statfile)));
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
return dbhash;
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
/*
* Verify it's of the expected format.
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
if (fread(&format_id, 1, sizeof(format_id), fpin) != sizeof(format_id) ||
format_id != PGSTAT_FILE_FORMAT_ID)
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
{
ereport(pgStatRunningInCollector ? LOG : WARNING,
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
(errmsg("corrupted statistics file \"%s\"", statfile)));
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
goto done;
}
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
/*
* Read global stats struct
*/
if (fread(&globalStats, 1, sizeof(globalStats), fpin) != sizeof(globalStats))
{
ereport(pgStatRunningInCollector ? LOG : WARNING,
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
(errmsg("corrupted statistics file \"%s\"", statfile)));
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
goto done;
}
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
/*
* Read archiver stats struct
*/
if (fread(&archiverStats, 1, sizeof(archiverStats), fpin) != sizeof(archiverStats))
{
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errmsg("corrupted statistics file \"%s\"", statfile)));
goto done;
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
* We found an existing collector stats file. Read it and put all the
* hashtable entries into place.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
for (;;)
{
switch (fgetc(fpin))
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
/*
* 'D' A PgStat_StatDBEntry struct describing a database
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* follows.
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
*/
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
case 'D':
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
if (fread(&dbbuf, 1, offsetof(PgStat_StatDBEntry, tables),
fpin) != offsetof(PgStat_StatDBEntry, tables))
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
ereport(pgStatRunningInCollector ? LOG : WARNING,
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
(errmsg("corrupted statistics file \"%s\"",
statfile)));
Use AllocateFile(), FreeFile() and palloc() rather than fopen(), fclose() and malloc() in pgstat.c, respectively. This simplifies error recovery, as well as being more consistent with the rest of the backend.
2004-10-28 03:38:41 +02:00
goto done;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
/*
* Add to the DB hash
*/
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
dbentry = (PgStat_StatDBEntry *) hash_search(dbhash,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(void *) &dbbuf.databaseid,
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
HASH_ENTER,
&found);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
if (found)
{
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
ereport(pgStatRunningInCollector ? LOG : WARNING,
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
(errmsg("corrupted statistics file \"%s\"",
statfile)));
Use AllocateFile(), FreeFile() and palloc() rather than fopen(), fclose() and malloc() in pgstat.c, respectively. This simplifies error recovery, as well as being more consistent with the rest of the backend.
2004-10-28 03:38:41 +02:00
goto done;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
memcpy(dbentry, &dbbuf, sizeof(PgStat_StatDBEntry));
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
dbentry->tables = NULL;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
dbentry->functions = NULL;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
* Don't collect tables if not the requested DB (or the
* shared-table info)
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
if (onlydb != InvalidOid)
{
if (dbbuf.databaseid != onlydb &&
dbbuf.databaseid != InvalidOid)
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
break;
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
memset(&hash_ctl, 0, sizeof(hash_ctl));
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
hash_ctl.keysize = sizeof(Oid);
Another round of cleanups for dynahash.c (maybe it's finally clean of portability issues). Caller-visible data structures are now allocated on MAXALIGN boundaries, allowing safe use of datatypes wider than 'long'. Rejigger hash_create API so that caller specifies size of key and total size of entry, not size of key and size of rest of entry. This simplifies life considerably since each number is just a sizeof(), and padding issues etc. are taken care of automatically.
2001-10-01 07:36:17 +02:00
hash_ctl.entrysize = sizeof(PgStat_StatTabEntry);
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
hash_ctl.hcxt = pgStatLocalContext;
Use AllocateFile(), FreeFile() and palloc() rather than fopen(), fclose() and malloc() in pgstat.c, respectively. This simplifies error recovery, as well as being more consistent with the rest of the backend.
2004-10-28 03:38:41 +02:00
dbentry->tables = hash_create("Per-database table",
PGSTAT_TAB_HASH_SIZE,
&hash_ctl,
Improve hash_create's API for selecting simple-binary-key hash functions. Previously, if you wanted anything besides C-string hash keys, you had to specify a custom hashing function to hash_create(). Nearly all such callers were specifying tag_hash or oid_hash; which is tedious, and rather error-prone, since a caller could easily miss the opportunity to optimize by using hash_uint32 when appropriate. Replace this with a design whereby callers using simple binary-data keys just specify HASH_BLOBS and don't need to mess with specific support functions. hash_create() itself will take care of optimizing when the key size is four bytes. This nets out saving a few hundred bytes of code space, and offers a measurable performance improvement in tidbitmap.c (which was not exploiting the opportunity to use hash_uint32 for its 4-byte keys). There might be some wins elsewhere too, I didn't analyze closely. In future we could look into offering a similar optimized hashing function for 8-byte keys. Under this design that could be done in a centralized and machine-independent fashion, whereas getting it right for keys of platform-dependent sizes would've been notationally painful before. For the moment, the old way still works fine, so as not to break source code compatibility for loadable modules. Eventually we might want to remove tag_hash and friends from the exported API altogether, since there's no real need for them to be explicitly referenced from outside dynahash.c. Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
hash_ctl.keysize = sizeof(Oid);
hash_ctl.entrysize = sizeof(PgStat_StatFuncEntry);
hash_ctl.hcxt = pgStatLocalContext;
dbentry->functions = hash_create("Per-database function",
PGSTAT_FUNCTION_HASH_SIZE,
&hash_ctl,
Improve hash_create's API for selecting simple-binary-key hash functions. Previously, if you wanted anything besides C-string hash keys, you had to specify a custom hashing function to hash_create(). Nearly all such callers were specifying tag_hash or oid_hash; which is tedious, and rather error-prone, since a caller could easily miss the opportunity to optimize by using hash_uint32 when appropriate. Replace this with a design whereby callers using simple binary-data keys just specify HASH_BLOBS and don't need to mess with specific support functions. hash_create() itself will take care of optimizing when the key size is four bytes. This nets out saving a few hundred bytes of code space, and offers a measurable performance improvement in tidbitmap.c (which was not exploiting the opportunity to use hash_uint32 for its 4-byte keys). There might be some wins elsewhere too, I didn't analyze closely. In future we could look into offering a similar optimized hashing function for 8-byte keys. Under this design that could be done in a centralized and machine-independent fashion, whereas getting it right for keys of platform-dependent sizes would've been notationally painful before. For the moment, the old way still works fine, so as not to break source code compatibility for loadable modules. Eventually we might want to remove tag_hash and friends from the exported API altogether, since there's no real need for them to be explicitly referenced from outside dynahash.c. Teodor Sigaev and Tom Lane
2014-12-18 19:36:29 +01:00
HASH_ELEM | HASH_BLOBS | HASH_CONTEXT);
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* If requested, read the data from the database-specific
* file. If there was onlydb specified (!= InvalidOid), we
* would not get here because of a break above. So we don't
* need to recheck.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
if (deep)
pgstat_read_db_statsfile(dbentry->databaseid,
dbentry->tables,
dbentry->functions,
permanent);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
break;
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
case 'E':
goto done;
default:
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errmsg("corrupted statistics file \"%s\"",
statfile)));
goto done;
}
}
done:
FreeFile(fpin);
/* If requested to read the permanent file, also get rid of it. */
if (permanent)
{
Fix assorted confusion between Oid and int32. In passing, also make some debugging elog's in pgstat.c a bit more consistently worded. Back-patch as far as applicable (9.3 or 9.4; none of these mistakes are really old). Mark Dilger identified and patched the type violations; the message rewordings are mine.
2014-12-11 21:41:15 +01:00
elog(DEBUG2, "removing permanent stats file \"%s\"", statfile);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
unlink(statfile);
}
return dbhash;
}
/* ----------
* pgstat_read_db_statsfile() -
*
* Reads in the existing statistics collector file for the given database,
* and initializes the tables and functions hash tables.
*
* As pgstat_read_statsfiles, if the permanent file is requested, it is
* removed after reading.
* ----------
*/
static void
pgstat_read_db_statsfile(Oid databaseid, HTAB *tabhash, HTAB *funchash,
bool permanent)
{
PgStat_StatTabEntry *tabentry;
PgStat_StatTabEntry tabbuf;
PgStat_StatFuncEntry funcbuf;
PgStat_StatFuncEntry *funcentry;
FILE *fpin;
int32 format_id;
bool found;
char statfile[MAXPGPATH];
get_dbstat_filename(permanent, false, databaseid, statfile, MAXPGPATH);
/*
* Try to open the stats file. If it doesn't exist, the backends simply
* return zero for anything and the collector simply starts from scratch
* with empty counters.
*
* ENOENT is a possibility if the stats collector is not running or has
* not yet written the stats file the first time. Any other failure
* condition is suspicious.
*/
if ((fpin = AllocateFile(statfile, PG_BINARY_R)) == NULL)
{
if (errno != ENOENT)
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errcode_for_file_access(),
errmsg("could not open statistics file \"%s\": %m",
statfile)));
return;
}
/*
* Verify it's of the expected format.
*/
if (fread(&format_id, 1, sizeof(format_id), fpin) != sizeof(format_id) ||
format_id != PGSTAT_FILE_FORMAT_ID)
{
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errmsg("corrupted statistics file \"%s\"", statfile)));
goto done;
}
/*
* We found an existing collector stats file. Read it and put all the
* hashtable entries into place.
*/
for (;;)
{
switch (fgetc(fpin))
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
/*
* 'T' A PgStat_StatTabEntry follows.
*/
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
case 'T':
Modify pgstats code to reduce performance penalties from oversized stats data files: avoid creating stats hashtable entries for tables that aren't being touched except by vacuum/analyze, ensure that entries for dropped tables are removed promptly, and tweak the data layout to avoid storing useless struct padding. Also improve the performance of pgstat_vacuum_tabstat(), and make sure that autovacuum invokes it exactly once per autovac cycle rather than multiple times or not at all. This should cure recent complaints about 8.1 showing much higher stats I/O volume than was seen in 8.0. It'd still be a good idea to revisit the design with an eye to not re-writing the entire stats dataset every half second ... but that would be too much to backpatch, I fear.
2006-01-18 21:35:06 +01:00
if (fread(&tabbuf, 1, sizeof(PgStat_StatTabEntry),
fpin) != sizeof(PgStat_StatTabEntry))
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
{
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
ereport(pgStatRunningInCollector ? LOG : WARNING,
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
(errmsg("corrupted statistics file \"%s\"",
statfile)));
Use AllocateFile(), FreeFile() and palloc() rather than fopen(), fclose() and malloc() in pgstat.c, respectively. This simplifies error recovery, as well as being more consistent with the rest of the backend.
2004-10-28 03:38:41 +02:00
goto done;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
/*
* Skip if table belongs to a not requested database.
*/
if (tabhash == NULL)
break;
Another round of cleanups for dynahash.c (maybe it's finally clean of portability issues). Caller-visible data structures are now allocated on MAXALIGN boundaries, allowing safe use of datatypes wider than 'long'. Rejigger hash_create API so that caller specifies size of key and total size of entry, not size of key and size of rest of entry. This simplifies life considerably since each number is just a sizeof(), and padding issues etc. are taken care of automatically.
2001-10-01 07:36:17 +02:00
tabentry = (PgStat_StatTabEntry *) hash_search(tabhash,
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
(void *) &tabbuf.tableid,
HASH_ENTER, &found);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
if (found)
{
Error message editing in backend/libpq, backend/postmaster, backend/tcop. Along the way, fix some logic problems in pgstat_initstats, notably the bogus assumption that malloc returns zeroed memory.
2003-07-22 21:00:12 +02:00
ereport(pgStatRunningInCollector ? LOG : WARNING,
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
(errmsg("corrupted statistics file \"%s\"",
statfile)));
Use AllocateFile(), FreeFile() and palloc() rather than fopen(), fclose() and malloc() in pgstat.c, respectively. This simplifies error recovery, as well as being more consistent with the rest of the backend.
2004-10-28 03:38:41 +02:00
goto done;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
memcpy(tabentry, &tabbuf, sizeof(tabbuf));
break;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/*
* 'F' A PgStat_StatFuncEntry follows.
*/
case 'F':
if (fread(&funcbuf, 1, sizeof(PgStat_StatFuncEntry),
fpin) != sizeof(PgStat_StatFuncEntry))
{
ereport(pgStatRunningInCollector ? LOG : WARNING,
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
(errmsg("corrupted statistics file \"%s\"",
statfile)));
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
goto done;
}
/*
* Skip if function belongs to a not requested database.
*/
if (funchash == NULL)
break;
funcentry = (PgStat_StatFuncEntry *) hash_search(funchash,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
(void *) &funcbuf.functionid,
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
HASH_ENTER, &found);
if (found)
{
ereport(pgStatRunningInCollector ? LOG : WARNING,
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
(errmsg("corrupted statistics file \"%s\"",
statfile)));
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
goto done;
}
memcpy(funcentry, &funcbuf, sizeof(funcbuf));
break;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
/*
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
* 'E' The EOF marker of a complete stats file.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
case 'E':
goto done;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
default:
ereport(pgStatRunningInCollector ? LOG : WARNING,
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
(errmsg("corrupted statistics file \"%s\"",
statfile)));
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
goto done;
}
}
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
done:
FreeFile(fpin);
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
if (permanent)
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
{
Fix assorted confusion between Oid and int32. In passing, also make some debugging elog's in pgstat.c a bit more consistently worded. Back-patch as far as applicable (9.3 or 9.4; none of these mistakes are really old). Mark Dilger identified and patched the type violations; the message rewordings are mine.
2014-12-11 21:41:15 +01:00
elog(DEBUG2, "removing permanent stats file \"%s\"", statfile);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
unlink(statfile);
}
Move pgstat.tmp into a temporary directory under $PGDATA named pg_stat_tmp. This allows the use of a ramdrive (either through mount or symlink) for the temporary file that's written every half second, which should reduce I/O. On server shutdown/startup, the file is written to the old location in the global directory, to preserve data across restarts. Bump catversion since the $PGDATA directory layout changed.
2008-08-05 14:09:30 +02:00
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
return;
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
/* ----------
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* pgstat_read_db_statsfile_timestamp() -
*
* Attempt to determine the timestamp of the last db statfile write.
* Returns TRUE if successful; the timestamp is stored in *ts.
*
* This needs to be careful about handling databases for which no stats file
* exists, such as databases without a stat entry or those not yet written:
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* - if there's a database entry in the global file, return the corresponding
* stats_timestamp value.
*
* - if there's no db stat entry (e.g. for a new or inactive database),
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
* there's no stats_timestamp value, but also nothing to write so we return
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* the timestamp of the global statfile.
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
* ----------
*/
static bool
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgstat_read_db_statsfile_timestamp(Oid databaseid, bool permanent,
TimestampTz *ts)
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
{
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
PgStat_StatDBEntry dbentry;
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
PgStat_GlobalStats myGlobalStats;
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
PgStat_ArchiverStats myArchiverStats;
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
FILE *fpin;
int32 format_id;
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
const char *statfile = permanent ? PGSTAT_STAT_PERMANENT_FILENAME : pgstat_stat_filename;
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
/*
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* Try to open the stats file. As above, anything but ENOENT is worthy of
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* complaining about.
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
*/
if ((fpin = AllocateFile(statfile, PG_BINARY_R)) == NULL)
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
{
if (errno != ENOENT)
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errcode_for_file_access(),
errmsg("could not open statistics file \"%s\": %m",
statfile)));
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
return false;
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
}
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
/*
* Verify it's of the expected format.
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
if (fread(&format_id, 1, sizeof(format_id), fpin) != sizeof(format_id) ||
format_id != PGSTAT_FILE_FORMAT_ID)
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
{
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errmsg("corrupted statistics file \"%s\"", statfile)));
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
FreeFile(fpin);
return false;
}
/*
* Read global stats struct
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
if (fread(&myGlobalStats, 1, sizeof(myGlobalStats),
fpin) != sizeof(myGlobalStats))
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
{
Add some logging code for unexpected cases in pgstat.c, particularly being unable to read a stats file for reasons other than ENOENT, and having to reset last_statrequest because it's later than current time in the collector. Not clear if this will shed any light on the "pgstat wait timeout" business, but it seems like a good idea in general. In passing, do some message-style-police work on recently-added pgstat_reset_shared_counters code.
2010-03-12 23:19:19 +01:00
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errmsg("corrupted statistics file \"%s\"", statfile)));
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
FreeFile(fpin);
return false;
}
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
/*
* Read archiver stats struct
*/
if (fread(&myArchiverStats, 1, sizeof(myArchiverStats),
fpin) != sizeof(myArchiverStats))
{
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errmsg("corrupted statistics file \"%s\"", statfile)));
FreeFile(fpin);
return false;
}
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/* By default, we're going to return the timestamp of the global file. */
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
*ts = myGlobalStats.stats_timestamp;
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/*
* We found an existing collector stats file. Read it and look for a
* record for the requested database. If found, use its timestamp.
*/
for (;;)
{
switch (fgetc(fpin))
{
/*
* 'D' A PgStat_StatDBEntry struct describing a database
* follows.
*/
case 'D':
if (fread(&dbentry, 1, offsetof(PgStat_StatDBEntry, tables),
fpin) != offsetof(PgStat_StatDBEntry, tables))
{
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errmsg("corrupted statistics file \"%s\"",
statfile)));
goto done;
}
/*
* If this is the DB we're looking for, save its timestamp and
* we're done.
*/
if (dbentry.databaseid == databaseid)
{
*ts = dbentry.stats_timestamp;
goto done;
}
break;
case 'E':
goto done;
default:
ereport(pgStatRunningInCollector ? LOG : WARNING,
(errmsg("corrupted statistics file \"%s\"",
statfile)));
goto done;
}
}
done:
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
FreeFile(fpin);
return true;
}
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
/*
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
* If not already done, read the statistics collector stats file into
* some hash tables. The results will be kept until pgstat_clear_snapshot()
* is called (typically, at end of transaction).
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
*/
static void
backend_read_statsfile(void)
{
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
TimestampTz min_ts = 0;
TimestampTz ref_ts = 0;
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
int count;
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
/* already read it? */
if (pgStatDBHash)
return;
Assert(!pgStatRunningInCollector);
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
/*
* Loop until fresh enough stats file is available or we ran out of time.
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
* The stats inquiry message is sent repeatedly in case collector drops
Remove debug logging for pgstat wait timeout. This reverts commit 79b2ee20c8a041a85dd230c4e787bef22edae57b, which proved to not be very informative; it looks like the "pgstat wait timeout" warnings in the buildfarm are just a symptom of running on heavily loaded machines, and there isn't any weird mechanism causing them to appear. To try to reduce the frequency of buildfarm failures from this effect, increase PGSTAT_MAX_WAIT_TIME from 5 seconds to 10. Also, arrange to not send a fresh inquiry message every single time through the loop, as that seems more likely to cause problems (by swamping the collector) than fix them. We'll now send an inquiry the first time through the delay loop, and every 640 msec thereafter.
2011-09-17 00:25:27 +02:00
* it; but not every single time, as that just swamps the collector.
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
*/
for (count = 0; count < PGSTAT_POLL_LOOP_COUNT; count++)
{
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
bool ok;
Fix compiler warning about uninitialized variable
2008-11-04 12:04:06 +01:00
TimestampTz file_ts = 0;
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
TimestampTz cur_ts;
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
CHECK_FOR_INTERRUPTS();
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
ok = pgstat_read_db_statsfile_timestamp(MyDatabaseId, false, &file_ts);
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
cur_ts = GetCurrentTimestamp();
/* Calculate min acceptable timestamp, if we didn't already */
if (count == 0 || cur_ts < ref_ts)
{
/*
* We set the minimum acceptable timestamp to PGSTAT_STAT_INTERVAL
* msec before now. This indirectly ensures that the collector
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* needn't write the file more often than PGSTAT_STAT_INTERVAL. In
* an autovacuum worker, however, we want a lower delay to avoid
* using stale data, so we use PGSTAT_RETRY_DELAY (since the
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
* number of workers is low, this shouldn't be a problem).
*
* We don't recompute min_ts after sleeping, except in the
* unlikely case that cur_ts went backwards. So we might end up
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* accepting a file a bit older than PGSTAT_STAT_INTERVAL. In
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
* practice that shouldn't happen, though, as long as the sleep
* time is less than PGSTAT_STAT_INTERVAL; and we don't want to
* tell the collector that our cutoff time is less than what we'd
* actually accept.
*/
ref_ts = cur_ts;
if (IsAutoVacuumWorkerProcess())
min_ts = TimestampTzPlusMilliseconds(ref_ts,
-PGSTAT_RETRY_DELAY);
else
min_ts = TimestampTzPlusMilliseconds(ref_ts,
-PGSTAT_STAT_INTERVAL);
}
/*
* If the file timestamp is actually newer than cur_ts, we must have
* had a clock glitch (system time went backwards) or there is clock
* skew between our processor and the stats collector's processor.
* Accept the file, but send an inquiry message anyway to make
* pgstat_recv_inquiry do a sanity check on the collector's time.
*/
if (ok && file_ts > cur_ts)
{
/*
* A small amount of clock skew between processors isn't terribly
* surprising, but a large difference is worth logging. We
* arbitrarily define "large" as 1000 msec.
*/
if (file_ts >= TimestampTzPlusMilliseconds(cur_ts, 1000))
{
char *filetime;
char *mytime;
/* Copy because timestamptz_to_str returns a static buffer */
filetime = pstrdup(timestamptz_to_str(file_ts));
mytime = pstrdup(timestamptz_to_str(cur_ts));
elog(LOG, "stats collector's time %s is later than backend local time %s",
filetime, mytime);
pfree(filetime);
pfree(mytime);
}
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgstat_send_inquiry(cur_ts, min_ts, MyDatabaseId);
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
break;
}
/* Normal acceptance case: file is not older than cutoff time */
if (ok && file_ts >= min_ts)
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
break;
/* Not there or too old, so kick the collector and wait a bit */
Remove debug logging for pgstat wait timeout. This reverts commit 79b2ee20c8a041a85dd230c4e787bef22edae57b, which proved to not be very informative; it looks like the "pgstat wait timeout" warnings in the buildfarm are just a symptom of running on heavily loaded machines, and there isn't any weird mechanism causing them to appear. To try to reduce the frequency of buildfarm failures from this effect, increase PGSTAT_MAX_WAIT_TIME from 5 seconds to 10. Also, arrange to not send a fresh inquiry message every single time through the loop, as that seems more likely to cause problems (by swamping the collector) than fix them. We'll now send an inquiry the first time through the delay loop, and every 640 msec thereafter.
2011-09-17 00:25:27 +02:00
if ((count % PGSTAT_INQ_LOOP_COUNT) == 0)
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgstat_send_inquiry(cur_ts, min_ts, MyDatabaseId);
Remove debug logging for pgstat wait timeout. This reverts commit 79b2ee20c8a041a85dd230c4e787bef22edae57b, which proved to not be very informative; it looks like the "pgstat wait timeout" warnings in the buildfarm are just a symptom of running on heavily loaded machines, and there isn't any weird mechanism causing them to appear. To try to reduce the frequency of buildfarm failures from this effect, increase PGSTAT_MAX_WAIT_TIME from 5 seconds to 10. Also, arrange to not send a fresh inquiry message every single time through the loop, as that seems more likely to cause problems (by swamping the collector) than fix them. We'll now send an inquiry the first time through the delay loop, and every 640 msec thereafter.
2011-09-17 00:25:27 +02:00
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
pg_usleep(PGSTAT_RETRY_DELAY * 1000L);
}
if (count >= PGSTAT_POLL_LOOP_COUNT)
Adjust "pgstat wait timeout" message to be a translatable LOG message. Per discussion, change the log level of this message to be LOG not WARNING. The main point of this change is to avoid causing buildfarm run failures when the stats collector is exceptionally slow to respond, which it not infrequently is on some of the smaller/slower buildfarm members. This change does lose notice to an interactive user when his stats query is looking at out-of-date stats, but the majority opinion (not necessarily that of yours truly) is that WARNING messages would probably not get noticed anyway on heavily loaded production systems. A LOG message at least ensures that the problem is recorded somewhere where bulk auditing for the issue is possible. Also, instead of an untranslated "pgstat wait timeout" message, provide a translatable and hopefully more understandable message "using stale statistics instead of current ones because stats collector is not responding". The original text was written hastily under the assumption that it would never really happen in practice, which we now know to be unduly optimistic. Back-patch to all active branches, since we've seen the buildfarm issue in all branches.
2015-01-20 05:01:33 +01:00
ereport(LOG,
(errmsg("using stale statistics instead of current ones "
"because stats collector is not responding")));
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/*
* Autovacuum launcher wants stats about all databases, but a shallow read
* is sufficient.
*/
Restructure autovacuum in two processes: a dummy process, which runs continuously, and requests vacuum runs of "autovacuum workers" to postmaster. The workers do the actual vacuum work. This allows for future improvements, like allowing multiple autovacuum jobs running in parallel. For now, the code keeps the original behavior of having a single autovac process at any time by sleeping until the previous worker has finished.
2007-02-16 00:23:23 +01:00
if (IsAutoVacuumLauncherProcess())
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgStatDBHash = pgstat_read_statsfiles(InvalidOid, false, false);
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
else
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
pgStatDBHash = pgstat_read_statsfiles(MyDatabaseId, false, true);
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
}
Integrate autovacuum functionality into the backend. There's still a few loose ends to be dealt with, but it seems to work. Alvaro Herrera, based on the contrib code by Matthew O'Connor.
2005-07-14 07:13:45 +02:00
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
/* ----------
* pgstat_setup_memcxt() -
*
* Create pgStatLocalContext, if not already done.
* ----------
*/
static void
pgstat_setup_memcxt(void)
{
if (!pgStatLocalContext)
pgStatLocalContext = AllocSetContextCreate(TopMemoryContext,
"Statistics snapshot",
ALLOCSET_SMALL_MINSIZE,
ALLOCSET_SMALL_INITSIZE,
ALLOCSET_SMALL_MAXSIZE);
Nested transactions. There is still much left to do, especially on the performance front, but with feature freeze upon us I think it's time to drive a stake in the ground and say that this will be in 7.5. Alvaro Herrera, with some help from Tom Lane.
2004-07-01 02:52:04 +02:00
}
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
/* ----------
* pgstat_clear_snapshot() -
*
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
* Discard any data collected in the current transaction. Any subsequent
Add a function pg_stat_clear_snapshot() that discards any statistics snapshot already collected in the current transaction; this allows plpgsql functions to watch for stats updates even though they are confined to a single transaction. Use this instead of the previous kluge involving pg_stat_file() to wait for the stats collector to update in the stats regression test. Internally, decouple storage of stats snapshots from transaction boundaries; they'll now stick around until someone calls pgstat_clear_snapshot --- which xact.c still does at transaction end, to maintain the previous behavior. This makes the logic a lot cleaner, at the price of a couple dozen cycles per transaction exit.
2007-02-08 00:11:30 +01:00
* request will cause new snapshots to be read.
*
* This is also invoked during transaction commit or abort to discard
* the no-longer-wanted snapshot.
* ----------
*/
void
pgstat_clear_snapshot(void)
{
/* Release memory, if any was allocated */
if (pgStatLocalContext)
MemoryContextDelete(pgStatLocalContext);
/* Reset variables */
pgStatLocalContext = NULL;
pgStatDBHash = NULL;
localBackendStatusTable = NULL;
localNumBackends = 0;
}
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
/* ----------
* pgstat_recv_inquiry() -
*
* Process stat inquiry requests.
* ----------
*/
static void
pgstat_recv_inquiry(PgStat_MsgInquiry *msg, int len)
{
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
slist_iter iter;
DBWriteRequest *newreq;
PgStat_StatDBEntry *dbentry;
Fix assorted confusion between Oid and int32. In passing, also make some debugging elog's in pgstat.c a bit more consistently worded. Back-patch as far as applicable (9.3 or 9.4; none of these mistakes are really old). Mark Dilger identified and patched the type violations; the message rewordings are mine.
2014-12-11 21:41:15 +01:00
elog(DEBUG2, "received inquiry for database %u", msg->databaseid);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/*
Remove useless variable Per Jeff Janes
2013-02-21 15:46:46 +01:00
* Find the last write request for this DB. If it's older than the
* request's cutoff time, update it; otherwise there's nothing to do.
*
* Note that if a request is found, we return early and skip the below
pgindent run for release 9.3 This is the first run of the Perl-based pgindent script. Also update pgindent instructions.
2013-05-29 22:58:43 +02:00
* check for clock skew. This is okay, since the only way for a DB
* request to be present in the list is that we have been here since the
* last write round.
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
*/
slist_foreach(iter, &last_statrequests)
{
DBWriteRequest *req = slist_container(DBWriteRequest, next, iter.cur);
if (req->databaseid != msg->databaseid)
continue;
if (msg->cutoff_time > req->request_time)
req->request_time = msg->cutoff_time;
return;
}
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
/*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* There's no request for this DB yet, so create one.
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
newreq = palloc(sizeof(DBWriteRequest));
newreq->databaseid = msg->databaseid;
newreq->request_time = msg->clock_time;
slist_push_head(&last_statrequests, &newreq->next);
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
/*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* If the requestor's local clock time is older than stats_timestamp, we
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
* should suspect a clock glitch, ie system time going backwards; though
* the more likely explanation is just delayed message receipt. It is
* worth expending a GetCurrentTimestamp call to be sure, since a large
* retreat in the system clock reading could otherwise cause us to neglect
* to update the stats file for a long time.
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
dbentry = pgstat_get_db_entry(msg->databaseid, false);
if ((dbentry != NULL) && (msg->clock_time < dbentry->stats_timestamp))
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
{
TimestampTz cur_ts = GetCurrentTimestamp();
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
if (cur_ts < dbentry->stats_timestamp)
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
{
/*
* Sure enough, time went backwards. Force a new stats file write
* to get back in sync; but first, log a complaint.
*/
char *writetime;
char *mytime;
/* Copy because timestamptz_to_str returns a static buffer */
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
writetime = pstrdup(timestamptz_to_str(dbentry->stats_timestamp));
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
mytime = pstrdup(timestamptz_to_str(cur_ts));
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
elog(LOG,
Fix assorted confusion between Oid and int32. In passing, also make some debugging elog's in pgstat.c a bit more consistently worded. Back-patch as far as applicable (9.3 or 9.4; none of these mistakes are really old). Mark Dilger identified and patched the type violations; the message rewordings are mine.
2014-12-11 21:41:15 +01:00
"stats_timestamp %s is later than collector's time %s for database %u",
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
writetime, mytime, dbentry->databaseid);
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
pfree(writetime);
pfree(mytime);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
newreq->request_time = cur_ts;
dbentry->stats_timestamp = cur_ts - 1;
Fix stats collector to recover nicely when system clock goes backwards. Formerly, if the system clock went backwards, the stats collector would fail to update the stats file any more until the clock reading again exceeds whatever timestamp was last written into the stats file. Such glitches in the clock's behavior are not terribly unlikely on machines not using NTP. Such a scenario has been observed to cause regression test failures in the buildfarm, and it could have bad effects on the behavior of autovacuum, so it seems prudent to install some defenses. We could directly detect the clock going backwards by adding GetCurrentTimestamp calls in the stats collector's main loop, but that would hurt performance on platforms where GetCurrentTimestamp is expensive. To minimize the performance hit in normal cases, adopt a more complicated scheme wherein backends check for clock skew when reading the stats file, and if they see it, signal the stats collector by sending an extra stats inquiry message. The stats collector does an extra GetCurrentTimestamp only when it receives an inquiry with an apparently out-of-order timestamp. To avoid unnecessary GetCurrentTimestamp calls, expand the inquiry messages to carry the backend's current clock reading as well as its stats cutoff time. The latter, being intentionally slightly in-the-past, would trigger more clock rechecks than we need if it were used for this purpose. We might want to backpatch this change at some point, but let's let it shake out in the buildfarm for awhile first.
2012-06-17 23:11:07 +02:00
}
}
Change the pgstat logic so that the stats collector writes the stats file only upon requests from backends, rather than on a fixed 500msec cycle. (There's still throttling logic to ensure it writes no more often than once per 500msec, though.) This should result in a significant reduction in stats file write traffic in typical scenarios where the stats are demanded only infrequently. This approach also means that the former difficulty with changing stats_temp_directory on-the-fly has gone away, so remove the caution about that as well as the thrashing we did to minimize the trouble window. In passing, also fix pgstat_report_stat() so that we will send a stats message if we have function call stats but not table stats to report; this fixes a bug in the recent patch to support function-call stats. Martin Pihlak
2008-11-03 02:17:08 +01:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/* ----------
* pgstat_recv_tabstat() -
*
* Count what the backend has done.
* ----------
*/
static void
pgstat_recv_tabstat(PgStat_MsgTabstat *msg, int len)
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
PgStat_StatDBEntry *dbentry;
PgStat_StatTabEntry *tabentry;
int i;
bool found;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
dbentry = pgstat_get_db_entry(msg->m_databaseid, true);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Remove the pgstats logic for delaying destruction of stats table entries. Per recent discussion, this seems to be making the stats less accurate rather than more so, particularly on Windows where PID values may be reused very quickly. Patch by Peter Brant.
2006-04-06 22:38:00 +02:00
* Update database-wide stats.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
dbentry->n_xact_commit += (PgStat_Counter) (msg->m_xact_commit);
dbentry->n_xact_rollback += (PgStat_Counter) (msg->m_xact_rollback);
Rename I/O timing statistics columns to blk_read_time and blk_write_time. This seems more consistent with the pre-existing choices for names of other statistics columns. Rename assorted internal identifiers to match.
2012-04-30 00:13:33 +02:00
dbentry->n_block_read_time += msg->m_block_read_time;
dbentry->n_block_write_time += msg->m_block_write_time;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
* Process all table entries in the message.
*/
for (i = 0; i < msg->m_nentries; i++)
{
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
PgStat_TableEntry *tabmsg = &(msg->m_entry[i]);
Another round of cleanups for dynahash.c (maybe it's finally clean of portability issues). Caller-visible data structures are now allocated on MAXALIGN boundaries, allowing safe use of datatypes wider than 'long'. Rejigger hash_create API so that caller specifies size of key and total size of entry, not size of key and size of rest of entry. This simplifies life considerably since each number is just a sizeof(), and padding issues etc. are taken care of automatically.
2001-10-01 07:36:17 +02:00
tabentry = (PgStat_StatTabEntry *) hash_search(dbentry->tables,
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
(void *) &(tabmsg->t_id),
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
HASH_ENTER, &found);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
if (!found)
{
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* If it's a new table entry, initialize counters to the values we
* just got.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
tabentry->numscans = tabmsg->t_counts.t_numscans;
tabentry->tuples_returned = tabmsg->t_counts.t_tuples_returned;
tabentry->tuples_fetched = tabmsg->t_counts.t_tuples_fetched;
tabentry->tuples_inserted = tabmsg->t_counts.t_tuples_inserted;
tabentry->tuples_updated = tabmsg->t_counts.t_tuples_updated;
tabentry->tuples_deleted = tabmsg->t_counts.t_tuples_deleted;
tabentry->tuples_hot_updated = tabmsg->t_counts.t_tuples_hot_updated;
tabentry->n_live_tuples = tabmsg->t_counts.t_delta_live_tuples;
tabentry->n_dead_tuples = tabmsg->t_counts.t_delta_dead_tuples;
tabentry->changes_since_analyze = tabmsg->t_counts.t_changed_tuples;
tabentry->blocks_fetched = tabmsg->t_counts.t_blocks_fetched;
tabentry->blocks_hit = tabmsg->t_counts.t_blocks_hit;
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
Add last-vacuum/analyze-time columns to the stats collector, both manual and issued by autovacuum. Add accessor functions to them, and use those in the pg_stat_*_tables system views. Catalog version bumped due to changes in the pgstat views and the pgstat file. Patch from Larry Rosenman, minor improvements by me.
2006-05-19 21:08:27 +02:00
tabentry->vacuum_timestamp = 0;
Zero out vacuum_count and related counters in pgstat_recv_tabstat(). This fixes an oversight in commit 946045f04d11d246a834b917a2b8bc6e4f884a37 of 2010-08-21, as reported by Itagaki Takahiro. Also a couple of minor cosmetic adjustments.
2011-03-07 17:17:06 +01:00
tabentry->vacuum_count = 0;
Add last-vacuum/analyze-time columns to the stats collector, both manual and issued by autovacuum. Add accessor functions to them, and use those in the pg_stat_*_tables system views. Catalog version bumped due to changes in the pgstat views and the pgstat file. Patch from Larry Rosenman, minor improvements by me.
2006-05-19 21:08:27 +02:00
tabentry->autovac_vacuum_timestamp = 0;
Zero out vacuum_count and related counters in pgstat_recv_tabstat(). This fixes an oversight in commit 946045f04d11d246a834b917a2b8bc6e4f884a37 of 2010-08-21, as reported by Itagaki Takahiro. Also a couple of minor cosmetic adjustments.
2011-03-07 17:17:06 +01:00
tabentry->autovac_vacuum_count = 0;
Add last-vacuum/analyze-time columns to the stats collector, both manual and issued by autovacuum. Add accessor functions to them, and use those in the pg_stat_*_tables system views. Catalog version bumped due to changes in the pgstat views and the pgstat file. Patch from Larry Rosenman, minor improvements by me.
2006-05-19 21:08:27 +02:00
tabentry->analyze_timestamp = 0;
Zero out vacuum_count and related counters in pgstat_recv_tabstat(). This fixes an oversight in commit 946045f04d11d246a834b917a2b8bc6e4f884a37 of 2010-08-21, as reported by Itagaki Takahiro. Also a couple of minor cosmetic adjustments.
2011-03-07 17:17:06 +01:00
tabentry->analyze_count = 0;
Add last-vacuum/analyze-time columns to the stats collector, both manual and issued by autovacuum. Add accessor functions to them, and use those in the pg_stat_*_tables system views. Catalog version bumped due to changes in the pgstat views and the pgstat file. Patch from Larry Rosenman, minor improvements by me.
2006-05-19 21:08:27 +02:00
tabentry->autovac_analyze_timestamp = 0;
Zero out vacuum_count and related counters in pgstat_recv_tabstat(). This fixes an oversight in commit 946045f04d11d246a834b917a2b8bc6e4f884a37 of 2010-08-21, as reported by Itagaki Takahiro. Also a couple of minor cosmetic adjustments.
2011-03-07 17:17:06 +01:00
tabentry->autovac_analyze_count = 0;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
else
{
/*
* Otherwise add the values to the existing entry.
*/
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
tabentry->numscans += tabmsg->t_counts.t_numscans;
tabentry->tuples_returned += tabmsg->t_counts.t_tuples_returned;
tabentry->tuples_fetched += tabmsg->t_counts.t_tuples_fetched;
tabentry->tuples_inserted += tabmsg->t_counts.t_tuples_inserted;
tabentry->tuples_updated += tabmsg->t_counts.t_tuples_updated;
tabentry->tuples_deleted += tabmsg->t_counts.t_tuples_deleted;
tabentry->tuples_hot_updated += tabmsg->t_counts.t_tuples_hot_updated;
Have TRUNCATE update pgstat tuple counters This works by keeping a per-subtransaction record of the ins/upd/del counters before the truncate, and then resetting them; this record is useful to return to the previous state in case the truncate is rolled back, either in a subtransaction or whole transaction. The state is propagated upwards as subtransactions commit. When the per-table data is sent to the stats collector, a flag indicates to reset the live/dead counters to zero as well. Catalog version bumped due to the change in pgstat format. Author: Alexander Shulgin Discussion: 1007.1207238291@sss.pgh.pa.us Discussion: 548F7D38.2000401@BlueTreble.com Reviewed-by: Álvaro Herrera, Jim Nasby
2015-02-20 16:10:01 +01:00
/* If table was truncated, first reset the live/dead counters */
if (tabmsg->t_counts.t_truncated)
{
tabentry->n_live_tuples = 0;
tabentry->n_dead_tuples = 0;
}
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
tabentry->n_live_tuples += tabmsg->t_counts.t_delta_live_tuples;
tabentry->n_dead_tuples += tabmsg->t_counts.t_delta_dead_tuples;
tabentry->changes_since_analyze += tabmsg->t_counts.t_changed_tuples;
tabentry->blocks_fetched += tabmsg->t_counts.t_blocks_fetched;
tabentry->blocks_hit += tabmsg->t_counts.t_blocks_hit;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/* Clamp n_live_tuples in case of negative delta_live_tuples */
Ooops, I was too busy worrying about getting the transactional infrastructure right to think carefully about how insert and delete counts map to n_live_tuples. Of course a deletion should reduce n_live_tuples.
2007-05-27 19:28:36 +02:00
tabentry->n_live_tuples = Max(tabentry->n_live_tuples, 0);
HOT updates. When we update a tuple without changing any of its indexed columns, and the new version can be stored on the same heap page, we no longer generate extra index entries for the new version. Instead, index searches follow the HOT-chain links to ensure they find the correct tuple version. In addition, this patch introduces the ability to "prune" dead tuples on a per-page basis, without having to do a complete VACUUM pass to recover space. VACUUM is still needed to clean up dead index entries, however. Pavan Deolasee, with help from a bunch of other people.
2007-09-20 19:56:33 +02:00
/* Likewise for n_dead_tuples */
tabentry->n_dead_tuples = Max(tabentry->n_dead_tuples, 0);
Ooops, I was too busy worrying about getting the transactional infrastructure right to think carefully about how insert and delete counts map to n_live_tuples. Of course a deletion should reduce n_live_tuples.
2007-05-27 19:28:36 +02:00
Add new columns for tuple statistics on a database level to pg_stat_database.
2007-03-16 18:57:36 +01:00
/*
Fix up pgstats counting of live and dead tuples to recognize that committed and aborted transactions have different effects; also teach it not to assume that prepared transactions are always committed. Along the way, simplify the pgstats API by tying counting directly to Relations; I cannot detect any redeeming social value in having stats pointers in HeapScanDesc and IndexScanDesc structures. And fix a few corner cases in which counts might be missed because the relation's pgstat_info pointer hadn't been set.
2007-05-27 05:50:39 +02:00
* Add per-table stats to the per-database entry, too.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
dbentry->n_tuples_returned += tabmsg->t_counts.t_tuples_returned;
dbentry->n_tuples_fetched += tabmsg->t_counts.t_tuples_fetched;
dbentry->n_tuples_inserted += tabmsg->t_counts.t_tuples_inserted;
dbentry->n_tuples_updated += tabmsg->t_counts.t_tuples_updated;
dbentry->n_tuples_deleted += tabmsg->t_counts.t_tuples_deleted;
dbentry->n_blocks_fetched += tabmsg->t_counts.t_blocks_fetched;
dbentry->n_blocks_hit += tabmsg->t_counts.t_blocks_hit;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
}
/* ----------
* pgstat_recv_tabpurge() -
*
* Arrange for dead table removal.
* ----------
*/
static void
pgstat_recv_tabpurge(PgStat_MsgTabpurge *msg, int len)
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
PgStat_StatDBEntry *dbentry;
int i;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
dbentry = pgstat_get_db_entry(msg->m_databaseid, false);
/*
* No need to purge if we don't even know the database.
*/
if (!dbentry || !dbentry->tables)
return;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
* Process all table entries in the message.
*/
for (i = 0; i < msg->m_nentries; i++)
{
Remove the pgstats logic for delaying destruction of stats table entries. Per recent discussion, this seems to be making the stats less accurate rather than more so, particularly on Windows where PID values may be reused very quickly. Patch by Peter Brant.
2006-04-06 22:38:00 +02:00
/* Remove from hashtable if present; we don't care if it's not. */
(void) hash_search(dbentry->tables,
(void *) &(msg->m_tableid[i]),
HASH_REMOVE, NULL);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
}
/* ----------
* pgstat_recv_dropdb() -
*
* Arrange for dead database removal
* ----------
*/
static void
pgstat_recv_dropdb(PgStat_MsgDropdb *msg, int len)
{
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
Oid dbid = msg->m_databaseid;
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
PgStat_StatDBEntry *dbentry;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
* Lookup the database in the hashtable.
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
dbentry = pgstat_get_db_entry(dbid, false);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* If found, remove it (along with the db statfile).
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
if (dbentry)
Remove the pgstats logic for delaying destruction of stats table entries. Per recent discussion, this seems to be making the stats less accurate rather than more so, particularly on Windows where PID values may be reused very quickly. Patch by Peter Brant.
2006-04-06 22:38:00 +02:00
{
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
char statfile[MAXPGPATH];
Remove the correct pgstat file on DROP DATABASE We were unlinking the permanent file, not the non-permanent one. But since the stat collector already unlinks all permanent files on startup, there was nothing for it to unlink. The non-permanent file remained in place, and was copied to the permanent directory on shutdown, so in effect no file was ever dropped. Backpatch to 9.3, where the issue was introduced by commit 187492b6c2e8. Before that, there were no per-database files and thus no file to drop on DROP DATABASE. Per report from Thom Brown. Author: Tomáš Vondra
2014-03-05 17:03:29 +01:00
get_dbstat_filename(false, false, dbid, statfile, MAXPGPATH);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
Fix assorted confusion between Oid and int32. In passing, also make some debugging elog's in pgstat.c a bit more consistently worded. Back-patch as far as applicable (9.3 or 9.4; none of these mistakes are really old). Mark Dilger identified and patched the type violations; the message rewordings are mine.
2014-12-11 21:41:15 +01:00
elog(DEBUG2, "removing stats file \"%s\"", statfile);
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
unlink(statfile);
Remove the pgstats logic for delaying destruction of stats table entries. Per recent discussion, this seems to be making the stats less accurate rather than more so, particularly on Windows where PID values may be reused very quickly. Patch by Peter Brant.
2006-04-06 22:38:00 +02:00
if (dbentry->tables != NULL)
hash_destroy(dbentry->tables);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
if (dbentry->functions != NULL)
hash_destroy(dbentry->functions);
Remove the pgstats logic for delaying destruction of stats table entries. Per recent discussion, this seems to be making the stats less accurate rather than more so, particularly on Windows where PID values may be reused very quickly. Patch by Peter Brant.
2006-04-06 22:38:00 +02:00
if (hash_search(pgStatDBHash,
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
(void *) &dbid,
Remove the pgstats logic for delaying destruction of stats table entries. Per recent discussion, this seems to be making the stats less accurate rather than more so, particularly on Windows where PID values may be reused very quickly. Patch by Peter Brant.
2006-04-06 22:38:00 +02:00
HASH_REMOVE, NULL) == NULL)
ereport(ERROR,
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
(errmsg("database hash table corrupted during cleanup --- abort")));
Remove the pgstats logic for delaying destruction of stats table entries. Per recent discussion, this seems to be making the stats less accurate rather than more so, particularly on Windows where PID values may be reused very quickly. Patch by Peter Brant.
2006-04-06 22:38:00 +02:00
}
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
/* ----------
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
* pgstat_recv_resetcounter() -
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*
This patch reduces the size of the message header used by statistics collector messages, per recent discussion on pgsql-patches. This actually required quite a few changes -- for example, "databaseid != InvalidOid" was used to check whether a slot in the backend entry table was initialized, but that no longer works since the slot might be initialized prior to receiving the BESTART message which contains the database id. We now use procpid > 0 to indicate that a slot is non-empty. Other changes: - various comment improvements and cleanups - there's no need to zero-out the entire activity buffer in pgstat_add_backend(), we can just set activity[0] to '\0'. - remove the counting of the # of connections to a database; this was not used anywhere One change in behavior I wasn't sure about: previously, the code would create a hash table entry for a database as soon as any message was received whose header referenced that database. Now, we only create hash table entries as needed (so for example BESTART won't create a database hash table entry, since it doesn't need to access anything in the per-db hash table). It would be easy enough to retain the old behavior, but AFAICS it is not required.
2005-05-11 03:41:41 +02:00
* Reset the statistics for the specified database.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
* ----------
*/
static void
pgstat_recv_resetcounter(PgStat_MsgResetcounter *msg, int len)
{
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
PgStat_StatDBEntry *dbentry;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
* Lookup the database in the hashtable. Nothing to do if not there.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
Clean up a number of autovacuum loose ends. Make the stats collector track shared relations in a separate hashtable, so that operations done from different databases are counted correctly. Add proper support for anti-XID-wraparound vacuuming, even in databases that are never connected to and so have no stats entries. Miscellaneous other bug fixes. Alvaro Herrera, some additional fixes by Tom Lane.
2005-07-29 21:30:09 +02:00
dbentry = pgstat_get_db_entry(msg->m_databaseid, false);
if (!dbentry)
return;
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
/*
Standard pgindent run for 8.1.
2005-10-15 04:49:52 +02:00
* We simply throw away all the database's table entries by recreating a
* new hash table for them.
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
*/
if (dbentry->tables != NULL)
hash_destroy(dbentry->tables);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
if (dbentry->functions != NULL)
hash_destroy(dbentry->functions);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
pgindent run on all C files. Java run to follow. initdb/regression tests pass.
2001-10-25 07:50:21 +02:00
dbentry->tables = NULL;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
dbentry->functions = NULL;
Reset all database-level stats in pgstat_recv_resetcounter(). We were failing to zero out some pg_stat_database counters that have been added since the initial pgstats coding. This is a bug, but not back-patching the fix since changing this behavior in a minor release seems a cure worse than the disease. Report and patch by Tomas Vondra.
2010-12-12 21:09:53 +01:00
/*
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
* Reset database-level stats, too. This creates empty hash tables for
* tables and functions.
Reset all database-level stats in pgstat_recv_resetcounter(). We were failing to zero out some pg_stat_database counters that have been added since the initial pgstats coding. This is a bug, but not back-patching the fix since changing this behavior in a minor release seems a cure worse than the disease. Report and patch by Tomas Vondra.
2010-12-12 21:09:53 +01:00
*/
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
reset_dbentry_counters(dbentry);
The new files for statistical system views. Jan
2001-06-22 21:18:36 +02:00
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
/* ----------
* pgstat_recv_resetshared() -
*
* Reset some shared statistics of the cluster.
* ----------
*/
static void
pgstat_recv_resetsharedcounter(PgStat_MsgResetsharedcounter *msg, int len)
{
pgindent run for 9.0
2010-02-26 03:01:40 +01:00
if (msg->m_resettarget == RESET_BGWRITER)
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
{
/* Reset the global background writer statistics for the cluster. */
memset(&globalStats, 0, sizeof(globalStats));
Track last time for statistics reset on databases and bgwriter Tracks one counter for each database, which is reset whenever the statistics for any individual object inside the database is reset, and one counter for the background writer. Tomas Vondra, reviewed by Greg Smith
2011-02-10 15:09:35 +01:00
globalStats.stat_reset_timestamp = GetCurrentTimestamp();
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
}
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
else if (msg->m_resettarget == RESET_ARCHIVER)
{
/* Reset the archiver statistics for the cluster. */
memset(&archiverStats, 0, sizeof(archiverStats));
archiverStats.stat_reset_timestamp = GetCurrentTimestamp();
}
Add pg_stat_reset_shared('bgwriter') to reset the cluster-wide shared statistics of the bgwriter. Greg Smith
2010-01-19 15:11:32 +01:00
/*
* Presumably the sender of this message validated the target, don't
* complain here if it's not valid
*/
}
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
/* ----------
* pgstat_recv_resetsinglecounter() -
*
* Reset a statistics for a single object
* ----------
*/
static void
pgstat_recv_resetsinglecounter(PgStat_MsgResetsinglecounter *msg, int len)
{
PgStat_StatDBEntry *dbentry;
dbentry = pgstat_get_db_entry(msg->m_databaseid, false);
if (!dbentry)
return;
Track last time for statistics reset on databases and bgwriter Tracks one counter for each database, which is reset whenever the statistics for any individual object inside the database is reset, and one counter for the background writer. Tomas Vondra, reviewed by Greg Smith
2011-02-10 15:09:35 +01:00
/* Set the reset timestamp for the whole database */
dbentry->stat_reset_timestamp = GetCurrentTimestamp();
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
/* Remove object if it exists, ignore it if not */
if (msg->m_resettype == RESET_TABLE)
Zero out vacuum_count and related counters in pgstat_recv_tabstat(). This fixes an oversight in commit 946045f04d11d246a834b917a2b8bc6e4f884a37 of 2010-08-21, as reported by Itagaki Takahiro. Also a couple of minor cosmetic adjustments.
2011-03-07 17:17:06 +01:00
(void) hash_search(dbentry->tables, (void *) &(msg->m_objectid),
HASH_REMOVE, NULL);
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
else if (msg->m_resettype == RESET_FUNCTION)
Zero out vacuum_count and related counters in pgstat_recv_tabstat(). This fixes an oversight in commit 946045f04d11d246a834b917a2b8bc6e4f884a37 of 2010-08-21, as reported by Itagaki Takahiro. Also a couple of minor cosmetic adjustments.
2011-03-07 17:17:06 +01:00
(void) hash_search(dbentry->functions, (void *) &(msg->m_objectid),
HASH_REMOVE, NULL);
Add functions to reset the statistics counter for a single table/index or a single function.
2010-01-28 15:25:41 +01:00
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
/* ----------
* pgstat_recv_autovac() -
*
* Process an autovacuum signalling message.
* ----------
*/
static void
pgstat_recv_autovac(PgStat_MsgAutovacStart *msg, int len)
{
PgStat_StatDBEntry *dbentry;
/*
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
* Store the last autovacuum time in the database's hashtable entry.
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
*/
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
dbentry = pgstat_get_db_entry(msg->m_databaseid, true);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
dbentry->last_autovac_time = msg->m_start_time;
}
/* ----------
* pgstat_recv_vacuum() -
*
* Process a VACUUM message.
* ----------
*/
static void
pgstat_recv_vacuum(PgStat_MsgVacuum *msg, int len)
{
PgStat_StatDBEntry *dbentry;
PgStat_StatTabEntry *tabentry;
/*
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
* Store the data in the table's hashtable entry.
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
*/
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
dbentry = pgstat_get_db_entry(msg->m_databaseid, true);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
tabentry = pgstat_get_tab_entry(dbentry, msg->m_tableoid, true);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Fix VACUUM's reporting of dead-tuple counts to the stats collector. Historically, VACUUM has just reported its new_rel_tuples estimate (the same thing it puts into pg_class.reltuples) to the stats collector. That number counts both live and dead-but-not-yet-reclaimable tuples. This behavior may once have been right, but modern versions of the pgstats code track live and dead tuple counts separately, so putting the total into n_live_tuples and zero into n_dead_tuples is surely pretty bogus. Fix it to report live and dead tuple counts separately. This doesn't really do much for situations where updating transactions commit concurrently with a VACUUM scan (possibly causing double-counting or omission of the tuples they add or delete); but it's clearly an improvement over what we were doing before. Hari Babu, reviewed by Amit Kapila
2014-01-19 01:24:20 +01:00
tabentry->n_live_tuples = msg->m_live_tuples;
tabentry->n_dead_tuples = msg->m_dead_tuples;
Improve the IndexVacuumInfo/IndexBulkDeleteResult API to allow somewhat sane behavior in cases where we don't know the heap tuple count accurately; in particular partial vacuum, but this also makes the API a bit more useful for ANALYZE. This patch adds "estimated_count" flags to both structs so that an approximate count can be flagged as such, and adjusts the logic so that approximate counts are not used for updating pg_class.reltuples. This fixes my previous complaint that VACUUM was putting ridiculous values into pg_class.reltuples for indexes. The actual impact of that bug is limited, because the planner only pays attention to reltuples for an index if the index is partial; which probably explains why beta testers hadn't noticed a degradation in plan quality from it. But it needs to be fixed. The whole thing is a bit messy and should be redesigned in future, because reltuples now has the potential to drift quite far away from reality when a long period elapses with no non-partial vacuums. But this is as good as it's going to get for 8.4.
2009-06-07 00:13:52 +02:00
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
if (msg->m_autovacuum)
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
{
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
tabentry->autovac_vacuum_timestamp = msg->m_vacuumtime;
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
tabentry->autovac_vacuum_count++;
}
Clamp last_anl_tuples to n_live_tuples, in case we vacuum a table without analyzing, so that future analyze threshold calculations don't get confused. Also, make sure we correctly track the decrease of live tuples cause by deletes. Per report from Dylan Hansen, patches by Tom Lane and me.
2006-06-27 05:45:16 +02:00
else
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
{
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
tabentry->vacuum_timestamp = msg->m_vacuumtime;
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
tabentry->vacuum_count++;
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
}
/* ----------
* pgstat_recv_analyze() -
*
* Process an ANALYZE message.
* ----------
*/
static void
pgstat_recv_analyze(PgStat_MsgAnalyze *msg, int len)
{
PgStat_StatDBEntry *dbentry;
PgStat_StatTabEntry *tabentry;
/*
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
* Store the data in the table's hashtable entry.
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
*/
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
dbentry = pgstat_get_db_entry(msg->m_databaseid, true);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Remove pgstat's discrimination against MsgVacuum and MsgAnalyze messages. Formerly, these message types would be discarded unless there was already a stats hash table entry for the target table. However, the intent of saving hash table space for unused tables was subverted by the fact that the physical I/O done by the vacuum or analyze would result in an immediately following tabstat message, which would create the hash table entry anyway. All that we had left was surprising loss of statistical data, as in a recent complaint from Jaime Casanova. It seems unlikely that a real database would have many tables that go totally untouched over the long haul, so the consensus is that this "optimization" serves little purpose anyhow. Remove it, and just create the hash table entry on demand in all cases.
2009-09-05 00:32:33 +02:00
tabentry = pgstat_get_tab_entry(dbentry, msg->m_tableoid, true);
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
Fix VACUUM so that it always updates pg_class.reltuples/relpages. When we added the ability for vacuum to skip heap pages by consulting the visibility map, we made it just not update the reltuples/relpages statistics if it skipped any pages. But this could leave us with extremely out-of-date stats for a table that contains any unchanging areas, especially for TOAST tables which never get processed by ANALYZE. In particular this could result in autovacuum making poor decisions about when to process the table, as in recent report from Florian Helmberger. And in general it's a bad idea to not update the stats at all. Instead, use the previous values of reltuples/relpages as an estimate of the tuple density in unvisited pages. This approach results in a "moving average" estimate of reltuples, which should converge to the correct value over multiple VACUUM and ANALYZE cycles even when individual measurements aren't very good. This new method for updating reltuples is used by both VACUUM and ANALYZE, with the result that we no longer need the grotty interconnections that caused ANALYZE to not update the stats depending on what had happened in the parent VACUUM command. Also, fix the logic for skipping all-visible pages during VACUUM so that it looks ahead rather than behind to decide what to do, as per a suggestion from Greg Stark. This eliminates useless scanning of all-visible pages at the start of the relation or just after a not-all-visible page. In particular, the first few pages of the relation will not be invariably included in the scanned pages, which seems to help in not overweighting them in the reltuples estimate. Back-patch to 8.4, where the visibility map was introduced.
2011-05-30 23:05:26 +02:00
tabentry->n_live_tuples = msg->m_live_tuples;
tabentry->n_dead_tuples = msg->m_dead_tuples;
Revise pgstat's tracking of tuple changes to improve the reliability of decisions about when to auto-analyze. The previous code depended on n_live_tuples + n_dead_tuples - last_anl_tuples, where all three of these numbers could be bad estimates from ANALYZE itself. Even worse, in the presence of a steady flow of HOT updates and matching HOT-tuple reclamations, auto-analyze might never trigger at all, even if all three numbers are exactly right, because n_dead_tuples could hold steady. To fix, replace last_anl_tuples with an accurately tracked count of the total number of committed tuple inserts + updates + deletes since the last ANALYZE on the table. This can still be compared to the same threshold as before, but it's much more trustworthy than the old computation. Tracking this requires one more intra-transaction counter per modified table within backends, but no additional memory space in the stats collector. There probably isn't any measurable speed difference; if anything it might be a bit faster than before, since I was able to eliminate some per-tuple arithmetic operations in favor of adding sums once per (sub)transaction. Also, simplify the logic around pgstat vacuum and analyze reporting messages by not trying to fold VACUUM ANALYZE into a single pgstat message. The original thought behind this patch was to allow scheduling of analyzes on parent tables by artificially inflating their changes_since_analyze count. I've left that for a separate patch since this change seems to stand on its own merit.
2009-12-30 21:32:14 +01:00
/*
* We reset changes_since_analyze to zero, forgetting any changes that
* occurred while the ANALYZE was in progress.
*/
tabentry->changes_since_analyze = 0;
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
if (msg->m_autovacuum)
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
{
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
tabentry->autovac_analyze_timestamp = msg->m_analyzetime;
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
tabentry->autovac_analyze_count++;
}
pgindent run for 8.2.
2006-10-04 02:30:14 +02:00
else
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
{
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
tabentry->analyze_timestamp = msg->m_analyzetime;
Add vacuum and analyze counters to pg_stat_*_tables views.
2010-08-21 12:59:17 +02:00
tabentry->analyze_count++;
}
Take the statistics collector out of the loop for monitoring backends' current commands; instead, store current-status information in shared memory. This substantially reduces the overhead of stats_command_string and also ensures that pg_stat_activity is fully up to date at all times. Per my recent proposal.
2006-06-19 03:51:22 +02:00
}
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
/* ----------
* pgstat_recv_archiver() -
*
* Process a ARCHIVER message.
* ----------
*/
static void
pgstat_recv_archiver(PgStat_MsgArchiver *msg, int len)
{
if (msg->m_failed)
{
/* Failed archival attempt */
++archiverStats.failed_count;
memcpy(archiverStats.last_failed_wal, msg->m_xlog,
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
sizeof(archiverStats.last_failed_wal));
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
archiverStats.last_failed_timestamp = msg->m_timestamp;
}
else
{
/* Successful archival operation */
++archiverStats.archived_count;
memcpy(archiverStats.last_archived_wal, msg->m_xlog,
pgindent run for 9.4 This includes removing tabs after periods in C comments, which was applied to back branches, so this change should not effect backpatching.
2014-05-06 18:12:18 +02:00
sizeof(archiverStats.last_archived_wal));
Add pg_stat_archiver statistics view. This view shows the statistics about the WAL archiver process's activity. Gabriele Bartolini, reviewed by Michael Paquier, refactored a bit by me.
2014-01-28 18:58:22 +01:00
archiverStats.last_archived_timestamp = msg->m_timestamp;
}
}
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
/* ----------
* pgstat_recv_bgwriter() -
*
* Process a BGWRITER message.
* ----------
*/
static void
Re-run pgindent with updated list of typedefs. (Updated README should avoid this problem in the future.)
2007-11-15 23:25:18 +01:00
pgstat_recv_bgwriter(PgStat_MsgBgWriter *msg, int len)
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
{
globalStats.timed_checkpoints += msg->m_timed_checkpoints;
globalStats.requested_checkpoints += msg->m_requested_checkpoints;
Publish checkpoint timing information to pg_stat_bgwriter. Greg Smith, Peter Geoghegan, and Robert Haas
2012-04-05 20:03:21 +02:00
globalStats.checkpoint_write_time += msg->m_checkpoint_write_time;
globalStats.checkpoint_sync_time += msg->m_checkpoint_sync_time;
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
globalStats.buf_written_checkpoints += msg->m_buf_written_checkpoints;
Implement "distributed" checkpoints in which the checkpoint I/O is spread over a fairly long period of time, rather than being spat out in a burst. This happens only for background checkpoints carried out by the bgwriter; other cases, such as a shutdown checkpoint, are still done at full speed. Remove the "all buffers" scan in the bgwriter, and associated stats infrastructure, since this seems no longer very useful when the checkpoint itself is properly throttled. Original patch by Itagaki Takahiro, reworked by Heikki Linnakangas, and some minor API editorialization by me.
2007-06-28 02:02:40 +02:00
globalStats.buf_written_clean += msg->m_buf_written_clean;
globalStats.maxwritten_clean += msg->m_maxwritten_clean;
Just-in-time background writing strategy. This code avoids re-scanning buffers that cannot possibly need to be cleaned, and estimates how many buffers it should try to clean based on moving averages of recent allocation requests and density of reusable buffers. The patch also adds a couple more columns to pg_stat_bgwriter to help measure the effectiveness of the bgwriter. Greg Smith, building on his own work and ideas from several other people, in particular a much older patch from Itagaki Takahiro.
2007-09-25 22:03:38 +02:00
globalStats.buf_written_backend += msg->m_buf_written_backend;
Add new buffers_backend_fsync field to pg_stat_bgwriter. This new field counts the number of times that a backend which writes a buffer out to the OS must also fsync() it. This happens when the bgwriter fsync request queue is full, and is generally detrimental to performance, so it's good to know when it's happening. Along the way, log a new message at level DEBUG1 whenever we fail to hand off an fsync, so that the problem can also be seen in examination of log files (if the logging level is cranked up high enough). Greg Smith, with minor tweaks by me.
2010-11-15 18:42:59 +01:00
globalStats.buf_fsync_backend += msg->m_buf_fsync_backend;
Just-in-time background writing strategy. This code avoids re-scanning buffers that cannot possibly need to be cleaned, and estimates how many buffers it should try to clean based on moving averages of recent allocation requests and density of reusable buffers. The patch also adds a couple more columns to pg_stat_bgwriter to help measure the effectiveness of the bgwriter. Greg Smith, building on his own work and ideas from several other people, in particular a much older patch from Itagaki Takahiro.
2007-09-25 22:03:38 +02:00
globalStats.buf_alloc += msg->m_buf_alloc;
Add some instrumentation to the bgwriter, through the stats collector. New view pg_stat_bgwriter, and the functions required to build it.
2007-03-30 20:34:56 +02:00
}
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
/* ----------
* pgstat_recv_recoveryconflict() -
*
Fix a copy/pasted typo in several comments
2012-01-26 16:02:33 +01:00
* Process a RECOVERYCONFLICT message.
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
* ----------
*/
static void
pgstat_recv_recoveryconflict(PgStat_MsgRecoveryConflict *msg, int len)
{
PgStat_StatDBEntry *dbentry;
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
dbentry = pgstat_get_db_entry(msg->m_databaseid, true);
switch (msg->m_reason)
{
case PROCSIG_RECOVERY_CONFLICT_DATABASE:
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
/*
pgindent run before PG 9.1 beta 1.
2011-04-10 17:42:00 +02:00
* Since we drop the information about the database as soon as it
* replicates, there is no point in counting these conflicts.
Add views and functions to monitor hot standby query conflicts Add the view pg_stat_database_conflicts and a column to pg_stat_database, and the underlying functions to provide the information.
2011-01-03 12:46:03 +01:00
*/
break;
case PROCSIG_RECOVERY_CONFLICT_TABLESPACE:
dbentry->n_conflict_tablespace++;
break;
case PROCSIG_RECOVERY_CONFLICT_LOCK:
dbentry->n_conflict_lock++;
break;
case PROCSIG_RECOVERY_CONFLICT_SNAPSHOT:
dbentry->n_conflict_snapshot++;
break;
case PROCSIG_RECOVERY_CONFLICT_BUFFERPIN:
dbentry->n_conflict_bufferpin++;
break;
case PROCSIG_RECOVERY_CONFLICT_STARTUP_DEADLOCK:
dbentry->n_conflict_startup_deadlock++;
break;
}
}
Add deadlock counter to pg_stat_database Adds a counter that tracks number of deadlocks that occurred in each database to pg_stat_database. Magnus Hagander, reviewed by Jaime Casanova
2012-01-26 15:58:19 +01:00
/* ----------
* pgstat_recv_deadlock() -
*
Fix a copy/pasted typo in several comments
2012-01-26 16:02:33 +01:00
* Process a DEADLOCK message.
Add deadlock counter to pg_stat_database Adds a counter that tracks number of deadlocks that occurred in each database to pg_stat_database. Magnus Hagander, reviewed by Jaime Casanova
2012-01-26 15:58:19 +01:00
* ----------
*/
static void
pgstat_recv_deadlock(PgStat_MsgDeadlock *msg, int len)
{
PgStat_StatDBEntry *dbentry;
dbentry = pgstat_get_db_entry(msg->m_databaseid, true);
dbentry->n_deadlocks++;
}
Track temporary file count and size in pg_stat_database Add counters for number and size of temporary files used for spill-to-disk queries for each database to the pg_stat_database view. Tomas Vondra, review by Magnus Hagander
2012-01-26 14:41:19 +01:00
/* ----------
* pgstat_recv_tempfile() -
*
Fix a copy/pasted typo in several comments
2012-01-26 16:02:33 +01:00
* Process a TEMPFILE message.
Track temporary file count and size in pg_stat_database Add counters for number and size of temporary files used for spill-to-disk queries for each database to the pg_stat_database view. Tomas Vondra, review by Magnus Hagander
2012-01-26 14:41:19 +01:00
* ----------
*/
static void
pgstat_recv_tempfile(PgStat_MsgTempFile *msg, int len)
{
PgStat_StatDBEntry *dbentry;
dbentry = pgstat_get_db_entry(msg->m_databaseid, true);
dbentry->n_temp_bytes += msg->m_filesize;
dbentry->n_temp_files += 1;
}
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
/* ----------
* pgstat_recv_funcstat() -
*
* Count what the backend has done.
* ----------
*/
static void
pgstat_recv_funcstat(PgStat_MsgFuncstat *msg, int len)
{
PgStat_FunctionEntry *funcmsg = &(msg->m_entry[0]);
PgStat_StatDBEntry *dbentry;
PgStat_StatFuncEntry *funcentry;
int i;
bool found;
dbentry = pgstat_get_db_entry(msg->m_databaseid, true);
/*
* Process all function entries in the message.
*/
for (i = 0; i < msg->m_nentries; i++, funcmsg++)
{
funcentry = (PgStat_StatFuncEntry *) hash_search(dbentry->functions,
8.4 pgindent run, with new combined Linux/FreeBSD/MinGW typedef list provided by Andrew.
2009-06-11 16:49:15 +02:00
(void *) &(funcmsg->f_id),
HASH_ENTER, &found);
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
if (!found)
{
/*
* If it's a new function entry, initialize counters to the values
* we just got.
*/
funcentry->f_numcalls = funcmsg->f_numcalls;
Converge all SQL-level statistics timing values to float8 milliseconds. This patch adjusts the core statistics views to match the decision already taken for pg_stat_statements, that values representing elapsed time should be represented as float8 and measured in milliseconds. By using float8, we are no longer tied to a specific maximum precision of timing data. (Internally, it's still microseconds, but we could now change that without needing changes at the SQL level.) The columns affected are pg_stat_bgwriter.checkpoint_write_time pg_stat_bgwriter.checkpoint_sync_time pg_stat_database.blk_read_time pg_stat_database.blk_write_time pg_stat_user_functions.total_time pg_stat_user_functions.self_time pg_stat_xact_user_functions.total_time pg_stat_xact_user_functions.self_time The first four of these are new in 9.2, so there is no compatibility issue from changing them. The others require a release note comment that they are now double precision (and can show a fractional part) rather than bigint as before; also their underlying statistics functions now match the column definitions, instead of returning bigint microseconds.
2012-04-30 20:02:47 +02:00
funcentry->f_total_time = funcmsg->f_total_time;
funcentry->f_self_time = funcmsg->f_self_time;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
}
else
{
/*
* Otherwise add the values to the existing entry.
*/
funcentry->f_numcalls += funcmsg->f_numcalls;
Converge all SQL-level statistics timing values to float8 milliseconds. This patch adjusts the core statistics views to match the decision already taken for pg_stat_statements, that values representing elapsed time should be represented as float8 and measured in milliseconds. By using float8, we are no longer tied to a specific maximum precision of timing data. (Internally, it's still microseconds, but we could now change that without needing changes at the SQL level.) The columns affected are pg_stat_bgwriter.checkpoint_write_time pg_stat_bgwriter.checkpoint_sync_time pg_stat_database.blk_read_time pg_stat_database.blk_write_time pg_stat_user_functions.total_time pg_stat_user_functions.self_time pg_stat_xact_user_functions.total_time pg_stat_xact_user_functions.self_time The first four of these are new in 9.2, so there is no compatibility issue from changing them. The others require a release note comment that they are now double precision (and can show a fractional part) rather than bigint as before; also their underlying statistics functions now match the column definitions, instead of returning bigint microseconds.
2012-04-30 20:02:47 +02:00
funcentry->f_total_time += funcmsg->f_total_time;
funcentry->f_self_time += funcmsg->f_self_time;
Add support for tracking call counts and elapsed runtime for user-defined functions. Note that because this patch changes FmgrInfo, any external C functions you might be testing with 8.4 will need to be recompiled. Patch by Martin Pihlak, some editorialization by me (principally, removing tracking of getrusage() numbers)
2008-05-15 02:17:41 +02:00
}
}
}
/* ----------
* pgstat_recv_funcpurge() -
*
* Arrange for dead function removal.
* ----------
*/
static void
pgstat_recv_funcpurge(PgStat_MsgFuncpurge *msg, int len)
{
PgStat_StatDBEntry *dbentry;
int i;
dbentry = pgstat_get_db_entry(msg->m_databaseid, false);
/*
* No need to purge if we don't even know the database.
*/
if (!dbentry || !dbentry->functions)
return;
/*
* Process all function entries in the message.
*/
for (i = 0; i < msg->m_nentries; i++)
{
/* Remove from hashtable if present; we don't care if it's not. */
(void) hash_search(dbentry->functions,
(void *) &(msg->m_functionid[i]),
HASH_REMOVE, NULL);
}
}
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
/* ----------
* pgstat_write_statsfile_needed() -
*
* Do we need to write out the files?
* ----------
*/
static bool
pgstat_write_statsfile_needed(void)
{
if (!slist_is_empty(&last_statrequests))
return true;
/* Everything was written recently */
return false;
}
/* ----------
* pgstat_db_requested() -
*
* Checks whether stats for a particular DB need to be written to a file.
* ----------
*/
static bool
pgstat_db_requested(Oid databaseid)
{
slist_iter iter;
Ensure that backends see up-to-date statistics for shared catalogs. Ever since we split the statistics collector's reports into per-database files (commit 187492b6c2e8cafc), backends have been seeing stale statistics for shared catalogs. This is because the inquiry message only prompts the collector to write the per-database file for the requesting backend's own database. Stats for shared catalogs are in a separate file for "DB 0", which didn't get updated. In normal operation this was partially masked by the fact that the autovacuum launcher would send an inquiry message at least once per autovacuum_naptime that asked for "DB 0"; so the shared-catalog stats would never be more than a minute out of date. However the problem becomes very obvious with autovacuum disabled, as reported by Peter Eisentraut. To fix, redefine the semantics of inquiry messages so that both the specified DB and DB 0 will be dumped. (This might seem a bit inefficient, but we have no good way to know whether a backend's transaction will look at shared-catalog stats, so we have to read both groups of stats whenever we request stats. Sending two inquiry messages would definitely not be better.) Back-patch to 9.3 where the bug was introduced. Report: <56AD41AC.1030509@gmx.net>
2016-05-25 23:48:15 +02:00
/*
* If any requests are outstanding at all, we should write the stats for
* shared catalogs (the "database" with OID 0). This ensures that
* backends will see up-to-date stats for shared catalogs, even though
* they send inquiry messages mentioning only their own DB.
*/
if (databaseid == InvalidOid && !slist_is_empty(&last_statrequests))
return true;
/* Search to see if there's an open request to write this database. */
Split pgstat file in smaller pieces We now write one file per database and one global file, instead of having the whole thing in a single huge file. This reduces the I/O that must be done when partial data is required -- which is all the time, because each process only needs information on its own database anyway. Also, the autovacuum launcher does not need data about tables and functions in each database; having the global stats for all DBs is enough. Catalog version bumped because we have a new subdir under PGDATA. Author: Tomas Vondra. Some rework by Álvaro Testing by Jeff Janes Other discussion by Heikki Linnakangas, Tom Lane.
2013-02-18 21:56:08 +01:00
slist_foreach(iter, &last_statrequests)
{
DBWriteRequest *req = slist_container(DBWriteRequest, next, iter.cur);
if (req->databaseid == databaseid)
return true;
}
return false;
}