On Fri, Feb 1, 2013 at 2:35 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> In any case, I no longer have much faith in the idea that letting
> GetOldestXmin go backwards is really safe.
That is admittedly kind of weird behavior, but I think one could
equally blame this on CLUSTER. This is hardly the first time we've
had to patch CLUSTER's handling of TOAST tables (cf commits
21b446dd0927f8f2a187d9461a0d3f11db836f77,
7b0d0e9356963d5c3e4d329a917f5fbb82a2ef05,
83b7584944b3a9df064cccac06822093f1a83793) and it doesn't seem unlikely
that we might go the full ten rounds.
Having said that, I agree that a fix in GetOldestXmin() would be nice
if we could find one, but since the comment describes at least three
different ways the value can move backwards, I'm not sure that there's
really a practical solution there, especially if you want something we
can back-patch. I'm more inclined to think that we need to find a way
to make CLUSTER more robust against xmin regressions, but I confess I
don't have any good ideas about how to do that, either.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
