Logging temp file useage ... a little advice would be appreciated
So I've got this patch (attached, against 8.2)
The goal is to track temp file usage as an aid to server tuning (such as
work_mem)
Most of the patch seems to work just dandy, except I'm getting weird
sizes reported:
2006-12-29 17:46:21 EST [45558]: [575-1] LOG: temp file: size 140737488343776 path base/32861/pgsql_tmp/pgsql_tmp45558.554
Seems a bit odd to have a 140T file on a 130G partition ...
I'm working on a FreeBSD 6.2 amd64 system. The headers show stat.st_size to
be of type off_t, which appears to be a 64-bit int. I figured that %ld
would be the correct format.
Am I hitting something such as file sparseness? Is this entire endeavour
doomed from the start? Or am I just making some sort of dumb mistake?
Any pointers are welcome.
--
Bill Moran
Collaborative Fusion Inc.
Attachments:
trace_log_files.difftext/x-diff; charset=iso-8859-1; name=trace_log_files.diffDownload
diff -r src.orig/backend/storage/file/fd.c src/backend/storage/file/fd.c
52a53
> #include "utils/guc.h"
941c942,943
< Vfd *vfdP;
---
> Vfd *vfdP;
> struct stat filestats;
970a973,981
> if (fstat(vfdP->fd, &filestats)) {
> if (trace_temp_files)
> ereport(LOG,
> (errmsg("temp file: size %ld path \"%s\"",
> filestats.st_size, vfdP->fileName)));
> PG_TRACE1(temp__file__cleanup, filestats.st_size);
> } else {
> elog(ERROR, "Could not stat \"%s\": %m", vfdP->fileName);
> }
diff -r src.orig/backend/utils/misc/guc.c src/backend/utils/misc/guc.c
183c183,184
<
---
> bool trace_temp_files = false;
>
1013c1014,1024
<
---
>
> {
> {"trace_temp_files", PGC_USERSET, LOGGING_WHAT,
> gettext_noop("Enables logging the usage of temp files."),
> gettext_noop("Size and location of each temp file is reported."),
> NULL
> },
> &trace_temp_files,
> false, NULL, NULL
> },
>
1474c1485
<
---
>
diff -r src.orig/backend/utils/misc/postgresql.conf.sample src/backend/utils/misc/postgresql.conf.sample
335a336
> #trace_temp_files = off # Log usage of temporary files
diff -r src.orig/include/utils/guc.h src/include/utils/guc.h
125a126
> extern bool trace_temp_files;
On Fri, 2006-12-29 at 17:53 -0500, Bill Moran wrote:
So I've got this patch (attached, against 8.2)
The goal is to track temp file usage as an aid to server tuning (such as
work_mem)Most of the patch seems to work just dandy, except I'm getting weird
sizes reported:2006-12-29 17:46:21 EST [45558]: [575-1] LOG: temp file: size 140737488343776 path base/32861/pgsql_tmp/pgsql_tmp45558.554
Seems a bit odd to have a 140T file on a 130G partition ...
The fd can be set to VFD_CLOSED just above where you've patched.
Try stat-ing the filename instead, as the unlink does.
Your patches should be diff -c format, submitted to -patches, please.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
Perhaps the file is not open at the time you are doing the fstat().
Also, context diffs (diff -c) are clearer for us.
---------------------------------------------------------------------------
Bill Moran wrote:
So I've got this patch (attached, against 8.2)
The goal is to track temp file usage as an aid to server tuning (such as
work_mem)Most of the patch seems to work just dandy, except I'm getting weird
sizes reported:2006-12-29 17:46:21 EST [45558]: [575-1] LOG: temp file: size 140737488343776 path base/32861/pgsql_tmp/pgsql_tmp45558.554
Seems a bit odd to have a 140T file on a 130G partition ...
I'm working on a FreeBSD 6.2 amd64 system. The headers show stat.st_size to
be of type off_t, which appears to be a 64-bit int. I figured that %ld
would be the correct format.Am I hitting something such as file sparseness? Is this entire endeavour
doomed from the start? Or am I just making some sort of dumb mistake?Any pointers are welcome.
--
Bill Moran
Collaborative Fusion Inc.
[ Attachment, skipping... ]
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +