Re: Rethinking stats communication mechanisms

On Sun, Jun 18, 2006 at 05:26:16PM -0400, Tom Lane wrote:
> 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
>

For a single writer, the algorithm is the latch routine that I
have described previously. If you call an odd value of the counter
the latch, then it would be:

Update -
1. Set counter to odd number.
2. Update content.
3. Increment counter which releases the latch.

Read -
1. Copy value of version into a register.
2. Read the content.
3. Read counter. If odd, go to 1.
4. If counter is different then that in register, go to 1.

For multiple writers, you will need an atomic action to set
the "latch".

Ken