Re: multixacts woes

From: José Luis Tallón <jltallon(at)adv-solutions(dot)net>
To: pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>
Cc: 'Robert Haas' <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: multixacts woes
Date: 2015-05-10 16:41:08
Message-ID: 554F8A24.6070900@adv-solutions.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2015-05-10 17:40:12 Re: multixacts woes
Previous Message Tom Lane 2015-05-10 16:09:41 Re: Manipulating complex types as non-contiguous structures in-memory