Re:HEAP_MOVED_IN during vacuum - test case
От | Stephen Birch |
---|---|
Тема | Re:HEAP_MOVED_IN during vacuum - test case |
Дата | |
Msg-id | 3878D740.78479672@ironmountainsystems.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Inprise/Borland releasing Interbase as Open source (The Hermit Hacker <scrappy@hub.org>) |
Ответы |
Re: [HACKERS] Re:HEAP_MOVED_IN during vacuum - test case
RE: [HACKERS] Re:HEAP_MOVED_IN during vacuum - test case Re: [HACKERS] Re:HEAP_MOVED_IN during vacuum - test case |
Список | pgsql-hackers |
I have now created a test case that demonstrate the HEAP_MOVED_IN during vacuum problem. Since the tar ball is 182k - I put it on an ftp site instead of mailing it. You can grab it from the following location: http://www.ironmountainsystems.com/heap_moved_in/ The tar ball contains two files - a shell script (show_bug) and a pg_dump dump. The shell script does the following using the dump file: 1. Create database ntis 2. Create table msg and populate it. 3. Use trim() twice. 4. Vacuum. The three interesting commands reside at the end of ntis.dmp: update msg set description = trim(description); update msg set owner = trim(owner); vacuum; when the script "show_bug" is run, we get the following output: CREATE DATABASE You are now connected to database ntis. CREATE UPDATE 12069 UPDATE 12069 ERROR: HEAP_MOVED_IN was not expected One interesting point: if either one of the trim operations is omitted, vacuum does not give the HEAP_MOVED_IN error. I also notice that if you change ntis.dmp so a vacuum is done between the two, the problem goes away. Any ideas? Tom Lane wrote: > The Hermit Hacker <scrappy@hub.org> writes: > > "However, the biggest problem was reported recently, see "HEAP_MOVED_IN > > during vacuum" posted on Saturday, no replies" ... > > > Anyone have any comments on that last one? > > I replied to it --- not with any useful ideas I'm afraid, just asking > for more info. But if Stephen is claiming he was ignored, then he's > not reading his email... > > regards, tom lane > > ************
В списке pgsql-hackers по дате отправления: