On 05/08/2015 09:57 PM, Josh Berkus wrote:
[snip]
It's certainly possible to have workloads triggering that, but I think
it's relatively uncommon. I in most cases I've checked the multixact
consumption rate is much lower than the xid consumption. There are some
exceptions, but often that's pretty bad code.
I have a couple workloads in my pool which do consume mxids faster than
xids, due to (I think) execeptional numbers of FK conflicts. It's
definitely unusual, though, and I'm sure they'd rather have corruption
protection and endure some more vacuums.
Seen corruption happen recently with OpenBravo on PostgreSQL 9.3.6
(Debian; binaries upgraded from 9.3.2) in a cluster pg_upgraded from 9.2.4
(albeit with quite insufficient autovacuum / poorly configured Postgres)
I fear that this might be more widespread than we thought, depending on
the exact workload/activity pattern.
If it would help, I can try to get hold of a copy of the cluster in
question (if the customer keeps any copy at all)
If we do this, though, it
might be worthwhile to backport the multixact age function, so that
affected users can check and schedule mxact wraparound vacuums
themselves, something you currently can't do on 9.3.
Thanks,
J.L.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
