Re: bgwriter stats
От | Neil Conway |
---|---|
Тема | Re: bgwriter stats |
Дата | |
Msg-id | 45FEF00C.4090808@samurai.com обсуждение исходный текст |
Ответ на | Re: bgwriter stats (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: bgwriter stats
|
Список | 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
В списке pgsql-patches по дате отправления: