Another race condition:
If a new tuple is inserted to the range while summarization runs, it's
possible that the new tuple isn't included in the tuple that the
summarization calculated, nor does the insertion itself udpate it.
1. There is no index tuple for page range 1-10
2. Summarization begins. It scans pages 1-5.
3. A new insertion inserts a heap tuple to page 1.
4. The insertion sees that there is no index tuple covering range 1-10,
so it doesn't update it.
5. The summarization finishes scanning pages 5-10, and inserts the new
index tuple. The summarization didn't see the newly inserted heap tuple,
and hence it's not included in the calculated index tuple.
One idea is to do the summarization in two stages. First, insert a
placeholder tuple, with no real value in it. A query considers the
placeholder tuple the same as a missing tuple, ie. always considers it a
match. An insertion updates the placeholder tuple with the value
inserted, as if it was a regular mmtuple. After summarization has
finished scanning the page range, it turns the placeholder tuple into a
regular tuple, by unioning the placeholder value with the value formed
by scanning the heap.
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: