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  (Magnus Hagander <magnus@hagander.net>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: bgwriter stats
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: bgwriter stats