Re: Re: yowch: dumpRules(): SELECT failed for table website.
От | Alfred Perlstein |
---|---|
Тема | Re: Re: yowch: dumpRules(): SELECT failed for table website. |
Дата | |
Msg-id | 20000524031006.U28097@fw.wintelcom.net обсуждение исходный текст |
Ответ на | Re: yowch: dumpRules(): SELECT failed for table website. (SL Baur <steve@beopen.com>) |
Список | pgsql-hackers |
* SL Baur <steve@beopen.com> [000524 02:59] wrote: > Alfred Perlstein <bright@wintelcom.net> writes in pgsql-hackers@postgresql.org: > > > while doing a pg_dump of a table after postgresql made a mess of itself: > > > dumpRules(): SELECT failed for table website. Explanation from > > backend: 'ERROR: cache lookup of attribute 1 in relation 9892634 > > failed '. > > I just got a message like that earlier this afternoon. My problem was > that I had created a view and later dropped and recreated one of the > tables the view referenced. Dropping and recreating the view fixed > things. I'm not using views afaik. There seems to be a serious corruption problem when a transaction is aborted, I'll see if I can have a reproduceable bug report tomorrow. Afaik it has to do with a transaction aborting after inserting or updating into a table. Something seems to go seriously wrong. We're also getting some problems when we don't "SET ENABLE_SEQSCAN=OFF;" for certain queries, Postgresql takes a really unoptimal path and will loop forever. Btw, is there any way to specify an abort timeout for a query if it's taking too long to just fail? -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk."
В списке pgsql-hackers по дате отправления: