On Wed, Dec 24, 2008 at 7:18 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>
>
>
> With respect, I was hoping you might look in the patch and see if you
> agree with the way it is handled. No need to remember. The whole
> latestRemovedXid concept is designed to do help.
>
Well, that's common for all cleanup record including vacuum. But
reading your comment, it seemed as there is something special to
handle HOT prune case which I did not see. Anyways, the trouble with
HOT prune is that uples may be cleaned up very frequently and that can
lead to query cancellation at the standby. That's what I wanted to
emphasize.
>
> Queries get cancelled if data they need to see if removed and the
> max_standby_delay expires. So lag will be max_standby_delay, by
> definition.
That's per cleanup record, isn't it ?
> We've also discussed storing lastCleanedLSN for each buffer, so queries
> can cancel themselves if they need to read a buffer that has had data
> removed from it that they would have needed to see. I'll write that up
> also.
>
What if we do that at table level ? So if a query touches a table
which had cleanup activity since the query was started, it cancels
itself automatically,
Happy X'mas to all of you!
Thanks,
Pavan
--
Pavan Deolasee
EnterpriseDB http://www.enterprisedb.com