On Thu, Dec 31, 2009 at 12:45 PM, Nicolas Barbier <nicolas.barb...@gmail.com> wrote: > * To answer your specific question: T0 might not read that specific > row, but the COUNT(..) definitely must read *something* that must be > modified by T1 when it updates the ishighlander field:
The problem occurs when the update happens. It doesn't have any way to know currently that a SELECT has already looked at that record and that the same transaction has performed an update which this transaction has already ignored when performing the count(*). The unsolved problems that have been raised are: - How and where do we have SELECTs note all the rows they read -- and all the rows they *would* have read that don't exist already. Note that something like select count(*) where id=? needs to be able to detect new rows from being inserted with the specified value, not merely lock the existing rows. - Can we do it without requiring major code changes in every index am and destroying modularity between the transaction management and the index api. - How do we do that without causing SELECTS to perform tons of write i/o they don't have to do now. People already complain about the hint bit updates the first time you do selects, doing i/o on every select would be disastrous. - Can we do that without destroying concurrency with course "locks" a la MySQL ISAM tables. - Can we do it without introducing unexpected serialization failure between transactions updating unrelated rows. Ideally, can we do it in a way that serialization errors are predictable rather than depending on access paths the planner chooses so they don't just randomly start happening when plans change. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
