From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PGSQL-Patches <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: bgwriter stats |
Date: | 2007-03-19 20:18:20 |
Message-ID: | 45FEF00C.4090808@samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Magnus Hagander wrote:
> Ok. But it should be safe if it's int32?
>
You should probably use sig_atomic_t, to be safe. Although I believe
that read/writes to "int" are atomic on most platforms, in any case.
> Actually, since it's just statistics data, it wouldn't be a problem that
> it's not atomic, I think. If we really unlucky, we'll get the wrong
> value once.
>
I don't think that's the right attitude to take, at all. Why not just
use a lock? It's not like the overhead will be noticeable.
Alternatively, you can get a consistent read from an int64 variable
using a sig_atomic_t counter, with a little thought. Off the top of my
head, something like the following should work: have the writer
increment the sig_atomic_t counter, adjust the int64 stats value, and
then increment the sig_atomic_t again. Have the reader save a local copy
of the sig_atomic_t counter aside, then read from the int64 counter, and
then recheck the sig_atomic_t counter. Repeat until the local pre-read
and post-read snapshots of the sig_atomic_t counter are identical.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2007-03-19 20:36:15 | Re: bgwriter stats |
Previous Message | Magnus Hagander | 2007-03-19 20:02:05 | Re: bgwriter stats |