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.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers