Re: Rethinking stats communication mechanisms

From: Kenneth Marshall <ktm(at)it(dot)is(dot)rice(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PFC <lists(at)peufeu(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Rethinking stats communication mechanisms
Date: 2006-06-19 13:14:22
Message-ID: 20060619131422.GR16371@it.is.rice.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-06-19 13:15:59 Re: table/index fillfactor control, try 2
Previous Message Kenneth Marshall 2006-06-19 12:57:21 Re: Rethinking stats communication mechanisms