Thanks Alvaro,for your deliberate explanation.But few more clarifications are requested as we are too novice to postgreSQL. 1)When it is said "upgrade" it is NOT the upgrade of table rather it is the upgrade that does happen because of vacuum query execution?..is that understanding right?.(Because we got the problem during normal query execution and not in postgreSQL upgrade) 2)Again what we could gather is,there is *a* chance of data corruption during vaccum query which might lead to core problem as well. The back trace what we have is , gdb) bt #0 0x449c210:0 in HeapTupleSatisfiesNow+0xb0 () #1 0x40ec3f0:0 in heap_fetch+0x6f0 () #2 0x41c1940:0 in analyze_rel+0x1540 () #3 0x42351d0:0 in vacuum+0x370 () #4 0x436adb0:0 in ProcessUtility+0xb00 () #5 0x4367b50:0 in PortalRunUtility+0x1c0 () #6 0x4368600:0 in PortalRun+0x950 () #7 0x435eab0:0 in exec_simple_query+0x530 () #8 0x4364550:0 in PostgresMain+0x45a0 () #9 0x4301c50:0 in ServerLoop+0x15e0 () #10 0x4306050:0 in PostmasterMain+0x2050 () #11 0x42858c0:0 in main+0x470 () Is there any point to think that it is the result of that corruption?.As we can observe,the core happened during the execution of HeapTupleSatisfiesNow which had a fix in later version for the said problem.does it vindicate core happened only because of the corruption which was there in earlier version of postgres.(Unfortunately we are still using older version.7.4.2 which didn't have the fix for the same.) Again Thanks a lot, Thanks , Prasanna. -----Original Message----- From: Alvaro Herrera [mailto:alvherre@xxxxxxxxxxxxxxxxx] Sent: Monday, July 30, 2007 10:00 PM To: Mavinakuli, Prasanna (STSD) Cc: pgsql-general@xxxxxxxxxxxxxx; Tom Lane; Rao, Srikanth R (STSD); Racharla, Chakravarthy (STSD); Manchenahalli, Raghunandan (STSD); Hebbar, Raghavendra (STSD) Subject: Re: Core reported from vaccum function. Mavinakuli, Prasanna (STSD) wrote: > > Hello Alvaro, > > Thanks for your reply. > > We could see > "Fix potential-data-corruption bug in how VACUUM FULL handles UPDATE > chains (Tom, Pavan Deolasee) " in 7.4.17 release notes. > > Could you please elaborate more on the above problem.Meaning what was > the actual problem and what fix has been done etc? Here is the CVS log entry: 2007-03-14 14:48 tgl * src/backend/commands/vacuum.c (1.263.2.3): Fix a longstanding bug in VACUUM FULL's handling of update chains. The code did not expect that a DEAD tuple could follow a RECENTLY_DEAD tuple in an update chain, but because the OldestXmin rule for determining deadness is a simplification of reality, it is possible for this situation to occur (implying that the RECENTLY_DEAD tuple is in fact dead to all observers, but this patch does not attempt to exploit that). The code would follow a chain forward all the way, but then stop before a DEAD tuple when backing up, meaning that not all of the chain got moved. This could lead to copying the chain multiple times (resulting in duplicate copies of the live tuple at its end), or leaving dangling index entries behind (which, aside from generating warnings from later vacuums, creates a risk of wrong query results or bogus duplicate-key errors once the heap slot the index entry points to is repopulated). The fix is to recheck HeapTupleSatisfiesVacuum while following a chain forward, and to stop if a DEAD tuple is reached. Each contiguous group of RECENTLY_DEAD tuples will therefore be copied as a separate chain. The patch also adds a couple of extra sanity checks to verify correct behavior. Per report and test case from Pavan Deolasee. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
