Re: Rethinking stats communication mechanisms - Mailing list pgsql-hackers

From Bort, Paul
Subject Re: Rethinking stats communication mechanisms
Date
Msg-id DB106B1B5B8F734B8FF3E155A3A556C202D4FBF4@clemail1.tmwsystems.com
Whole thread Raw
In response to Re: Rethinking stats communication mechanisms  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Rethinking stats communication mechanisms  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>
> > 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?
>

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.

This might be assuming too much about what the writer knows about the
current contents of the counter, but since it's per-back end, I think it
would work.

Regards,
Paul Bort


pgsql-hackers by date:

Previous
From: Michael Fuhr
Date:
Subject: Re: regresssion script hole
Next
From: Tom Lane
Date:
Subject: Re: Rethinking stats communication mechanisms