Simon Riggs <simon@2ndquadrant.com> writes:
> On Fri, 2008-01-25 at 19:02 -0500, Tom Lane wrote:
>> This seems large, complex, and untested (I note in particular a
>> guaranteed-to-fail Assert).
> Yes, its for discussion. How would you describe such a patch in the
> future? I want to be able to differentiate patch status.
"Completely untested" might be an appropriate description ...
> We only clean the queue if a long run of messages is read by the oldest
> message reader, so when stateP->nextMsgNum == segP->minMsgNum && number
> of messages read > 25% of queue. So that is only performed by a backend
> waking up to find it is behind, such as would happen if a PM signal had
> been issued.
You still haven't explained why that won't happen in parallel within
many backends at once. I really think we need to fix things so that
catchup interrupts occur serially instead of all at once.
>> Do you have any evidence for performance improvement?
> ISTM that it would only be worth testing when we had a rough agreement
> that we had found a reasonable approach.
Well, what I'd like to do for 8.4 is a considerably more invasive
rethink of the signaling logic. I'm not opposed in principle to some
simpler stopgap fix for 8.3, but at this late stage of the cycle there
would have to be a pretty compelling performance-improvement case for
it. So I'm not sure of the point of posting a patch that's not even
ready for performance testing.
regards, tom lane