Re: assertion failure 9.3.4
От | Andrew Dunstan |
---|---|
Тема | Re: assertion failure 9.3.4 |
Дата | |
Msg-id | 534F3B20.6010900@dunslane.net обсуждение исходный текст |
Ответ на | Re: assertion failure 9.3.4 (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: assertion failure 9.3.4
Re: assertion failure 9.3.4 |
Список | pgsql-hackers |
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. Not sure where that gets us in terms of deciding on a culprit. cheers andrew
В списке pgsql-hackers по дате отправления: