Re: Rethinking stats communication mechanisms

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Rethinking stats communication mechanisms
Дата
Msg-id 23719.1150665976@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Rethinking stats communication mechanisms  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Rethinking stats communication mechanisms  ("Bort, Paul" <pbort@tmwsystems.com>)
Re: Rethinking stats communication mechanisms  (Kenneth Marshall <ktm@it.is.rice.edu>)
Список pgsql-hackers
I wrote:
> PFC <lists@peufeu.com> writes:
>> So, the proposal :
>> On executing a command, Backend stores the command string, then  
>> overwrites the counter with (counter + 1) and with the timestamp of  
>> command start.
>> Periodically, like every N seconds, a separate process reads the counter,  
>> then reads the data, then reads the counter again.

> BTW, I think the writer would actually need to bump the counter twice,
> once before and once after it modifies its stats area.  Else there's
> no way to detect that you've copied a partially-updated stats entry.

Actually, neither of these ideas works: it's possible that the reader
copies the entry between the two increments of the counter.  Then, it
won't see any reason to re-read, but nonetheless it has copied an
inconsistent partially-modified entry.

Anyone know a variant of this that really works?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hannu Krosing
Дата:
Сообщение: Re: Rethinking stats communication mechanisms
Следующее
От: Andrew Dunstan
Дата:
Сообщение: regresssion script hole