On Wed, Dec 24, 2008 at 7:18 PM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
