Re: Breakage with VACUUM ANALYSE + partitions
От | Michael Paquier |
---|---|
Тема | Re: Breakage with VACUUM ANALYSE + partitions |
Дата | |
Msg-id | CAB7nPqSBFmh5cQjpRbFBp9Rkv1nF=Nh2o1FxKkJ6yvOBtvYDBA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Breakage with VACUUM ANALYSE + partitions (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Breakage with VACUUM ANALYSE + partitions
Re: Breakage with VACUUM ANALYSE + partitions |
Список | pgsql-bugs |
On Thu, Mar 24, 2016 at 9:40 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Mar 24, 2016 at 12:59 AM, Haribabu Kommi > <kommi.haribabu@gmail.com> wrote: >> So further operations on the table uses the already constructed smgr relation >> and treats that there are RELSEG_SIZE number of blocks in the page and try >> to do the scan. But there are 0 pages in the table thus it produces the error. >> >> The issue doesn't occur from another session. Because of this reason only >> if we do only vacuum operation, the error not occurred. > > Yeah, I had a suspicion that this might have to do with invalidation > messages based on Thom's description, but I think we still need to > track down which commit is at fault. I could reproduce the failure on Linux, not on OSX, and bisecting the failure, the first bad commit is this one: commit: 428b1d6b29ca599c5700d4bc4f4ce4c5880369bf author: Andres Freund <andres@anarazel.de> date: Thu, 10 Mar 2016 17:04:34 -0800 Allow to trigger kernel writeback after a configurable number of writes. The failure is a little bit sporadic, based on my tests 1/2 runs out of 10 could pass, so one good commit was recognized as such after passing the SQL sequence sent by Thom 5 times in a row. I also did some manual tests and those are pointing to this commit as well. I am adding Fabien and Andres in CC for some feedback. -- Michael
В списке pgsql-bugs по дате отправления: