On 2015-06-02 11:16:22 -0400, Robert Haas wrote: > I'm having trouble figuring out what to do about this. I mean, the > essential principle of this patch is that if we can't count on > relminmxid, datminmxid, or the control file to be accurate, we can at > least look at what is present on the disk. If we also cannot count on > that to be accurate, we are left without any reliable source of > information. Consider a hypothetical cluster where all our stored > minmxids of whatever form are corrupted (say, all change to 1) and in > addition there are stray files in pg_multixact. I don't think there's > really any way to get ourselves out of trouble in that scenario. If we were to truncate after vacuum, and only on the primary (via WAL logging), we could, afaics, just rely on all the values to be recomputed. I mean relminmxid will be recomputed after a vacuum, and thus, after some time, will datminmxid and the control file value. We could just force a value of 1 to always trigger anti-wraparound vacuums (or wait for that to happen implicitly, to delay the impact?). That'll then should then fix the problem in a relatively short amount of time? -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
