On Thu, 2011-07-28 at 18:48 +0200, Hannu Krosing wrote:
> On Thu, 2011-07-28 at 18:05 +0200, Hannu Krosing wrote:
>
> > But it is also possible, that you can get logically consistent snapshots
> > by protecting only some ops. for example, if you protect only insert and
> > get snapshot, then the worst that can happen is that you get a snapshot
> > that is a few commits older than what youd get with full locking and it
> > may well be ok for all real uses.
>
> Thinking more of it, we should lock commit/remove_txid and get_snapshot
>
> having a few more running backends does not make a difference, but
> seeing commits in wrong order may.
Sorry, not true as this may advanxe xmax to include some running
transactions which were missed during memcpy.
so we still need some mechanism to either synchronize the the copy with
both inserts and removes, or make it atomic even in presence of multiple
CPUs.
> this will cause contention between commit and get_snapshot, but
> hopefully less than current ProcArray manipulation, as there is just one
> simple C array to lock and copy.
>
--
-------
Hannu Krosing
PostgreSQL Infinite Scalability and Performance Consultant
PG Admin Book: http://www.2ndQuadrant.com/books/
