I wrote:
> * ProcArrayInstallImportedXmin and ProcArrayInstallRestoredXmin will
> forcibly overwrite MyPgXact->xmin with some random xmin or other.
> While they take pains to ensure that doesn't cause the global xmin
> horizon to go backwards,
and while we're on the subject, I doubt that those pains are sufficient.
Assume that xact A is importing an xmin from xact B, and meanwhile xact
C is attempting to determine the global xmin. Since the above-mentioned
functions take the ProcArrayLock in shared mode, these things can happen
concurrently. Assume that the xmin in question is the oldest one in the
system, and consider the following sequence of events:
1. C's scan of the procarray reaches xact A. Its xmin isn't set yet,
so nothing happens.
2. A imports xmin from B. Now A's xmin is set, but too late for C
to notice.
3. B resets its MyPgXact->xmin to zero. Even though it's not allowed to
exit its transaction because C still has the shared ProcArrayLock, that
doesn't stop B from running SnapshotResetXmin intra-transaction.
4. C's scan of the procarray reaches xact B. B's xmin is now zero,
so that doesn't inform C either.
Upshot: A now has an xmin that is before C's opinion of the global
xmin, allowing C to prune away data that A needs.
In practice this may not be a live bug, because I suspect that we don't
export snapshots that wouldn't be kept till end-of-transaction, so that
B would not actually advance/clear its xmin while C holds the lock.
But there's certainly nothing protecting against it in procarray.c,
and no documentation of the hazard anyplace.
regards, tom lane