Gregory Stark wrote:
> 6) 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?
In normal operation, any transaction that's in-progress has an entry in
ProcArray. GetSnapshot() gathers the xids of all those in-progress
transactions, so that they're seen as not-committed even when the
they're later marked as committed in clog.
In HS, we might see the first WAL record of transaction 10 before we see
the first WAL record of transaction 9. Without unobserved_xids, if you
take a snapshot in the standby between those two WAL records, xid 10 is
included in the snapshot, but 9 is not. If xact 9 later commits, it's
marked in clog as committed, and it will suddenly appear as visible to
the snapshot. To avoid that, when we replay the first WAL record of xact
10, we also add 9 to the unobserved xid array, so that it's included in
snapshots.
So, you can think of the unobserved xids array as an extension of
ProcArray. The entries are like light-weight PGPROC entries. In fact I
proposed earlier to simply create dummy PGPROC entries instead.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com