From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Bort, Paul" <pbort(at)tmwsystems(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Rethinking stats communication mechanisms |
Date: | 2006-06-19 03:07:41 |
Message-ID: | 9205.1150686461@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"Bort, Paul" <pbort(at)tmwsystems(dot)com> writes:
>> Anyone know a variant of this that really works?
> Here's a theory: If the counter is bumped to an odd number before
> modification, and an even number after it's done, then the reader will
> know it needs to re-read if the counter is an odd number.
Great minds think alike ;-) ... I just committed exactly that protocol.
I believe it is correct, because AFAICS there are only four possible
risk cases:
* reader's read starts before and ends after writer's update: reader
will certainly note a change in update counter.
* reader's read starts before and ends within writer's update: reader
will note a change in update counter.
* reader's read starts within and ends after writer's update: reader
will note a change in update counter.
* reader's read starts within and ends within writer's update: reader
will see update counter as odd.
Am I missing anything?
Note in particular that this protocol does not assume atomic update
of the counter, so we don't need to worry about whether int is
sig_atomic_t. If any of the bytes change, we have what we need.
We could use a counter narrower than int, but then there's some tiny
risk that the counter could wrap all the way around while the reader
is blocked.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2006-06-19 03:34:06 | kill_prior_tuple for bitmap scan |
Previous Message | Bort, Paul | 2006-06-19 02:49:11 | Re: Rethinking stats communication mechanisms |