Re: Performance monitor signal handler

From: Alfred Perlstein <bright(at)wintelcom(dot)net>
To: Philip Warner <pjw(at)rhyme(dot)com(dot)au>
Cc: Jan Wieck <janwieck(at)Yahoo(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Performance monitor signal handler
Date: 2001-03-16 00:55:19
Message-ID: 20010315165519.J29888@fw.wintelcom.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Philip Warner <pjw(at)rhyme(dot)com(dot)au> [010315 16:46] wrote:
> At 16:17 15/03/01 -0800, Alfred Perlstein wrote:
> >
> >Lost data is probably better than incorrect data. Either use locks
> >or a copying mechanism. People will depend on the data returned
> >making sense.
> >
>
> But with per-backend data, there is only ever *one* writer to a given set
> of counters. Everyone else is a reader.

This doesn't prevent a reader from getting an inconsistant view.

Think about a 64bit counter on a 32bit machine. If you charged per
megabyte, wouldn't it upset you to have a small chance of loosing
4 billion units of sale?

(ie, doing a read after an addition that wraps the low 32 bits
but before the carry is done to the top most signifigant 32bits?)

Ok, what what if everything can be read atomically by itself?

You're still busted the minute you need to export any sort of
compound stat.

If A, B and C need to add up to 100 you have a read race.

--
-Alfred Perlstein - [bright(at)wintelcom(dot)net|alfred(at)freebsd(dot)org]

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2001-03-16 00:56:34 Re: Allowing WAL fsync to be done via O_SYNC
Previous Message Justin Clift 2001-03-16 00:50:25 Re: Allowing WAL fsync to be done via O_SYNC