| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Jan Wieck <JanWieck(at)Yahoo(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Phil Endecott <spam_from_postgresql_general(at)chezphil(dot)org>, pgsql-general(at)postgresql(dot)org, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Subject: | Re: Megabytes of stats saved after every connection |
| Date: | 2005-07-28 19:06:34 |
| Message-ID: | 87ack692dh.fsf@stark.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Jan Wieck <JanWieck(at)Yahoo(dot)com> writes:
> Then again, the stats file is only written. There is nothing that actually
> forces the blocks out. On a busy system, one individual stats file will be
> created, written to, renamed, live for 500ms and be thrown away by the next
> stat files rename operation. I would assume that with a decent filesystem and
> appropriate OS buffers, none of the data blocks of most stat files even hit the
> disk. I must be missing something.
Renaming is a metadata operation. Depending on the filesystem it has to be
done either synchronously or force a log write barrier. I'm not sure how those
things are implemented in various filesystems but I could easily imagine some
implementations treating them as implicit fsyncs for that file.
Perhaps this user could put the stats file in a ramdisk. It doesn't sound like
losing it in a crash would be anything to worry about.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2005-07-28 19:12:33 | Re: Megabytes of stats saved after every connection |
| Previous Message | Scott Marlowe | 2005-07-28 19:01:19 | Re: Megabytes of stats saved after every connection |