Re: advancing snapshot's xmin

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> I think you probably do. GetSnapshotData needs to be confident that the
>> global xmin it computes is <= the xmin that any other backend might be
>> about to store into its MyProc->xmin; how can you ensure that if there's
>> no locking happening?

> Surely xmin would only ever advance?

You couldn't guarantee that without any lock. The risk case is where
someone else is in progress of setting his own xmin, but is running so
slowly that he's included an XID that isn't there anymore. So someone
else coming in and doing a computation of global xmin will compute a
higher value than what the slow guy is about to publish.

I agree that it would be safe for a backend to increase its
already-published xmin to some higher value without a lock. But I don't
see the point. The place where you'd actually be computing the new
value is in GetSnapshotData, and that can't run without a lock for the
above-mentioned reason.

> It's the same locking in theory from the point of view of where in the code
> the locking happens. But I don't think it's the same locking in practice from
> the point of view of how much wall-clock time passes between locks.

> Consider a data loading job which has millions of INSERT statements in a file.
> Currently if you put them all in a transaction it takes a single snapshot and
> runs them all with the same snapshot.

> If you reset xmin whenever you have no live snapshots then that job would be
> doing that between every INSERT statement.

These statements are 100% nonsense.

regards, tom lane