Re: Hot standby and b-tree killed items
От | Pavan Deolasee |
---|---|
Тема | Re: Hot standby and b-tree killed items |
Дата | |
Msg-id | 2e78013d0812241041h79d25dd9g43966f285e812d28@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Hot standby and b-tree killed items (Simon Riggs <simon@2ndQuadrant.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: