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
Re: Rethinking stats communication mechanisms |
Список | 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 по дате отправления: