Dmitry Yemanov wrote:

>"Ann W. Harrison" <aharrison@...> wrote:
>
>
>>He stores a record in thread1 and commits it, then wakes
>>thread2. Thread2 doesn't immediately see the new record,
>>but does eventually. In thinking it over, I'm not at all
>>sure how or when the state of newly committed transactions
>>is conveyed to separate classic processes. Do you know?
>>
>>
>
>VIO asks TRA_snapshot_state(). For read-committed, TRA_snapshot_state()
>relies on the transaction cache. TPC_snapshot_state() returns its cached
>value only if it's committed or dead. For supposedly active transaction it
>tries to get a lock of the transaction ID. If failed - return active. If
>succeeded, refetch the TIP.
>
>Looks correct and reliable for classic at the first glance.
>
>
>
>

Unfortunately, the transaction cache isn't reliable for this purpose,
though ironically, it is for normal transactions.

Probably the best way to fix read committed transaction is for
TRA_snapshot_state to refer to the tip rather than the cache. It's a
page fetch but a page fetch that's a guaranteed cache hit unless the TIP
been changed by another process, which is exactly what is required. It
does mean that read committed "transactions" induce a higher system cost
than reliable transactions, but I rather believe this sends the right
message.