On Fri, Aug 30, 2013 at 12:59 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
>> But I think that actually coordinating a consistent visibility order
>> between commit, wal insertion and the procarray would have bigger
>> scalability impact than the second record. I might be missing some
>> clever tricks here though.
>
> Yeah. ISTM the only way to really guarantee that the visible commit
> order is the same would be for transactions to hold the ProcArrayLock
> while they're inserting that WAL record. Needless to say, that would
> be absolutely disastrous performance-wise.
>
> Or at least, that's true as long as we rely on the current procarray-based
> mechanism for noting that a transaction is still in progress. Maybe
> there's some other approach altogether.
This is exactly what I'm working on. Under my scheme snapshots can be
taken completely lock free, without consulting the procarray at all,
and commits only need to exclude other commits from the moment that
visibility order is determined to when it's safe to become visible. If
we don't have any constraints on visibility order this is only a
matter of looking up the transactions slot in a shared memory
structure and writing the next commit sequence number there. I
described the approach in a lot more detail a couple of months ago.
[1] For now I'm going to leave the semantics as is and be content that
we will have a better foundation to do something about it later.
[1] http://www.postgresql.org/message-id/CA+CSw_tEpJ=md1zgxPkjH6CWDnTDft4gBi=+P9SnoC+Wy3pKdA@mail.gmail.com
Regards,
Ants Aasma
