Keeping iterator in consistent state

I was reading this post to understand how things are done in Sql Server:
http://rusanu.com/2013/08/01/understanding-how-sql-server-executes-a-query/

If I understand it correctly, data is being sent to client as is being needed. Before we fetch next batch of data to the client, execution of query is suspended. If we do range scan then metadata about last returned row will be stored somewhere.
What happens if in the meantime there is a page split and last returned row is on the new page?
Is this possible? Does this operator/iterator (clustered index scan for example) holds latch on page whole time?
This would be extremely inefficient, so Sql Server must have some other way to keep it in sync?

My question is - what metadata is stored and how does Sql Server keep it in sync?

No SQL Server does not hold a latch. The storage engine keeps track of the current index scan position using a "cookie". The cookie is revalidated if another process takes a latch (of a type that means the page might have been changed) on the same page since the cookie was acquired.

If the cookie (scan position) is no longer valid, the b-tree structure is traversed (using key + uniquifier information stored in the cookie) to reacquire the correct position, and the cookie updated.

In case it is of interest, here is a stack capture when the saved position is validated:

And another one just after cookie validation has failed due to a concurrent incompatible latch. The engine is repositioning the scan position using a seek to find the correct new position:

There are performance counters related to cookie activity, for example Scan Point Revalidations/sec and Used page/leaf page cookie.

There is no public documentation that describes exactly how this all works. The details above are based on observations, subsequently confirmed in conversations with Paul Randal and Bob Ward.

StackExchange Database Administrators Q#87001, answer score: 11