On Tue, Dec 18, 2012 at 7:59 PM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2012-12-18 19:56:18 -0500, Robert Haas wrote: >> On Tue, Dec 18, 2012 at 5:25 PM, anara...@anarazel.de >> <and...@anarazel.de> wrote: >> > The problem is that at the time GetSnapshotData returns the xmin horizon >> > might have gone upwards and tuples required for decoding might get removed >> > by other backends. That needs to be prevented while holding the procarray >> > lock exclusively. >> >> Well, for the ordinary use of GetSnapshotData(), that doesn't matter, >> because GetSnapshotData() also updates proc->xmin. If you're trying >> to store a different value in that field then of course it matters. > > Absolutely right. I don't want to say there's anything wrong with it > right now. The "problem" for me is that it sets proc->xmin to the newest > value it can while I want/need the oldest valid value... > > I will go with adding a already_locked parameter to GetOldestXmin then.
Or instead of bool already_locked, maybe bool advertise_xmin? Seems like that might be more friendly to the abstraction boundaries. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
