From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | PFC <lists(at)peufeu(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Rethinking stats communication mechanisms |
Date: | 2006-06-18 21:26:16 |
Message-ID: | 23719.1150665976@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> PFC <lists(at)peufeu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2006-06-18 21:30:55 | regresssion script hole |
Previous Message | Hannu Krosing | 2006-06-18 19:30:19 | Re: Rethinking stats communication mechanisms |