On Wed, 2009-01-28 at 18:55 +0000, Gregory Stark wrote:
> I still don't understand why you need unobserved_xids. We don't need
> this in normal running, an xid we don't know for certain is committed
> is exactly the same as a transaction we know is currently running or
> aborted. So why do you need it during HS?
All running transactions need to be part of the snapshot. This is true
on both standby and primary.
On primary we allocate new xids from a single counter, so there are no
gaps. Newly assigned xids go straight into the procarray and then are
removed later when they commit/abort.
In standby we only know what is in WAL. Xid assignment is not currently
WAL logged, so either we choose to WAL log each new xid and face the
performance consequences (IMHO, unacceptable), or we choose a different
strategy. UnobservedXids is that different strategy. Florian Pflug had a
different strategy, but he did have a strategy.
> The comment says:
>
> + * This is very important because if we leave
> + * those xids out of the snapshot then they will appear to be
> already complete.
> + * Later, when they have actually completed this could lead to
> confusion as to
> + * whether those xids are visible or not, blowing a huge hole in
> MVCC.
> + * We need 'em.
>
> But that doesn't sound rational to me. I'm not sure what "confusion"
> this would cause. If they later actually complete then any existing
> snapshots would still not see them. And any later snapshots wouldn't
> be confused by the earlier conclusions.
If a xact is running when we take a snapshot, yet we do not include it
then bad things will happen, but not til later. If a xact is not in
snapshot *and* less than xamx then we presume it completed prior to the
snapshot. If that xact did subsequently commit *after* we took the
snapshot, then it's absence from the snapshot will make that data
visible if the xact committed, making it look like it committed *before*
the snapshot was taken. So the "confusion" results in an MVCC violation
and so we must handle this case correctly, or die.
-- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
