Andrew Dunstan wrote:
>
> On 04/16/2014 07:19 PM, Tom Lane wrote:
> >Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> >>I'm not quite clear on why the third query, the one in ri_PerformCheck,
> >>is invoking a sequence.
> >It's not --- SeqNext is the next-tuple function for a sequential scan.
> >Nothing to do with sequences.
> >
> >Now, it *is* worth wondering why the heck a query on the table's primary
> >key is using a seqscan and not an indexscan. Maybe the planner thinks
> >there are just a few rows in the table? But the stack trace seems
> >unexceptional other than that.
> >
> >I'm wondering if the combination of autoexplain and pg_stat_statements
> >is causing trouble.
> >
> >Yeah, it would be real nice to see a self-contained test case for this.
>
> Well, that might be hard to put together, but I did try running
> without pg_stat_statements and auto_explain loaded and the error did
> not occur.
Well, can you get us the queries that are being run, and the schemas
involved in those queries?
> Not sure where that gets us in terms of deciding on a
> culprit.
I suspect, in the blind, that autoexplain is executing a query that
causes a second update XID to be added to a multixact (which already has
another one), perhaps with the same snapshot as the original update.
Why would this be happening in a FK-check query? No idea.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services