PG Manual: Clarifying the repeatable read isolation example

Feel free to flame me if I should be posting this elsewhere, but after reading the "submitting a patch" guide, it
appearsI should ask for guidance here. 


I was reading the Postgres MVCC documentation today (which is generally fantastic BTW), and am slightly confused by a
singlesentence example, describing possible read-only snapshot isolation anomalies. I would like to submit a patch to
clarifythis example, since I suspect others may be also confused, but to do that I need help understanding it. The
examplewas added as part of the Serializable Snapshot Isolation patch. 

Link to the commit: http://git.postgresql.org/gitweb/?p=postgresql.git;h=dafaa3efb75ce1aae2e6dbefaf6f3a889dea0d21


I'm referring to the following sentence of 13.2.2, which is still in the source tree:

http://www.postgresql.org/docs/devel/static/transaction-iso.html#XACT-REPEATABLE-READ

"For example, even a read only transaction at this level may see a control record updated to show that a batch has been
completedbut not see one of the detail records which is logically part of the batch because it read an earlier revision
ofthe control record." 


I do not understand how this example anomaly is possible. I'm imagining something like the following:

1. Do a bunch of work, possibly in parallel in multiple transactions, that insert/update a bunch of detail records.
2. After all that work commits, insert or update a record in the "control" table indicating that the batch completed.

Or maybe:

1. Do a batch of work and update the "control" table in a single transaction.


The guarantee that I believe REPEATABLE READ will give you in either of these case is that if you see the "control"
tablerecord, you will read all the detail records, because the control record is only written if the updated detail
recordshave been committed. What am I not understanding? 


The most widely cited read-only snapshot isolation example is the bank withdrawl example from this paper:
http://www.sigmod.org/publications/sigmod-record/0409/2.ROAnomONeil.pdf. However, I suspect we can present an anomaly
thatdoesn't require as much explanation? 

Thanks,

Evan Jones

--
Work: https://www.mitro.co/    Personal: http://evanjones.ca/