Re: Performance monitor signal handler - Mailing list pgsql-hackers

From Alfred Perlstein
Subject Re: Performance monitor signal handler
Date
Msg-id 20010315165519.J29888@fw.wintelcom.net
Whole thread Raw
In response to Re: Performance monitor signal handler  (Philip Warner <pjw@rhyme.com.au>)
Responses Re: Performance monitor signal handler  (Philip Warner <pjw@rhyme.com.au>)
List pgsql-hackers
* Philip Warner <pjw@rhyme.com.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@wintelcom.net|alfred@freebsd.org]



pgsql-hackers by date:

Previous
From: Justin Clift
Date:
Subject: Re: Allowing WAL fsync to be done via O_SYNC
Next
From: Bruce Momjian
Date:
Subject: Re: Allowing WAL fsync to be done via O_SYNC