Re: Sync Rep: First Thoughts on Code

Heikki Linnakangas wrote:
> Mark Mielke wrote:
>> FYI: I haven't been able to prove this. Multiple sessions running on
>> my dual-core CPU seem to be able to see the latest commits before
>> they begin executing. Am I wrong about this? Does PostgreSQL provide
>> a intentional guarantee that a commit from one session that completes
>> immediately followed by a query from another session will always find
>> the commit effect visible (provide the transaction isolation level
>> doesn't get in the way)?
> Yes. PostgreSQL does guarantee that, and I would expect any other DBMS
> to do the same.

Where does the expectation come from? I don't recall ever reading it in
the documentation, and unless the session processes are contending over
the integers (using some sort of synchronization primitive) in memory
that represent the "latest visible commit" on every single select, I'm
wondering how it is accomplished? If they are contending over these
integers, doesn't that represent a scaling limitation, in the sense that
on a 32-core machine, they're going to be fighting with each other to
get the latest version of these shared integers into the CPU for
processing? Maybe it's such a small penalty that we don't care? :-)

I was never instilled with the logic that 'commit in one session
guarantees visibility of the effects in another session'. But, as I say
above, I wasn't able to make PostgreSQL "fail" in this regard. So maybe
I have no clue what I am talking about? :-)

If you happen to know where the code or documentation makes this
promise, feel free to point it out. I'd like to review the code. If you
don't know - don't worry about it, I'll find it later...

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>