Andrew Dunstan wrote: > > On 04/16/2014 07:19 PM, Tom Lane wrote: > >Alvaro Herrera <alvhe...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers