Обсуждение: Core reported from vaccum function.
Hello All, We are getting the following core more oftenly.But We don't have a test case where it is guaranteed to dump this core.We are using 7.4.2 version postgres and if any one of you aware about some bug fixes happened around this problem.Please let us know. Thanks, Prasanna. Core was generated by `postmaster'. Program terminated with signal 10, Bus error. BUS_ADRALN - Invalid address alignment #0 0x449c210:0 in HeapTupleSatisfiesNow+0xb0 () (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 ()
Mavinakuli, Prasanna (STSD) wrote: > Hello All, > > We are getting the following core more oftenly.But We don't have a test > case where it is guaranteed to dump this core.We are using 7.4.2 version > postgres and if any one of you aware about some bug fixes happened > around this problem.Please let us know. There are about 15 rounds of bug fixes released after that version. Get 7.4.17 and try again. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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.
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@commandprompt.com]
Sent: Monday, July 30, 2007 10:00 PM
To: Mavinakuli, Prasanna (STSD)
Cc: pgsql-general@postgresql.org; Tom Lane; Rao, Srikanth R (STSD);
Racharla, Chakravarthy (STSD); Manchenahalli, Raghunandan (STSD);
Hebbar, Raghavendra (STSD)
Subject: Re: [GENERAL] 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.
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? Thanks a lot for all your help/time. Thanks, Prasanna. -----Original Message----- From: Alvaro Herrera [mailto:alvherre@commandprompt.com] Sent: Tuesday, June 19, 2007 8:44 AM To: Mavinakuli, Prasanna (STSD) Cc: Tom Lane; pgsql-general@postgresql.org; Rao, Srikanth R (STSD) Subject: Re: [GENERAL] Core reported from vaccum function. Mavinakuli, Prasanna (STSD) wrote: > Hello All, > > We are getting the following core more oftenly.But We don't have a > test case where it is guaranteed to dump this core.We are using 7.4.2 > version postgres and if any one of you aware about some bug fixes > happened around this problem.Please let us know. There are about 15 rounds of bug fixes released after that version. Get 7.4.17 and try again. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Mavinakuli, Prasanna (STSD) wrote: > > Thanks Alvaro,for your deliberate explanation.But few more > clarifications are requested as we are too novice to postgreSQL. Let me give you this piece of advice, since you are too novice to PostgreSQL: Do NOT continue to run 7.4.2. Upgrade to 7.4.17. Not doing so is just a waste of your time and ours. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Mavinakuli, Prasanna (STSD) wrote: > > > > Thanks Alvaro,for your deliberate explanation.But few more > > clarifications are requested as we are too novice to postgreSQL. > > Let me give you this piece of advice, since you are too novice to > PostgreSQL: > > Do NOT continue to run 7.4.2. Upgrade to 7.4.17. Not doing so is just > a waste of your time and ours. Agreed. Not upgrading is more risky than upgrading. This is in the FAQ. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Mavinakuli, Prasanna (STSD) wrote: > Hello Alvaro, > > Thanks Alvaro for your time and suggestions.Yes we do understand that we > are expected to use the higher versions.But as Bruce pointed out > already,the same is NOT recommended when there is NO imperative > reason.Hence we were just in the process of validating and justifying > the upgrade. You are mistaken. Bruce said exactly the opposite. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
"Mavinakuli, Prasanna (STSD)" <prasanna.b-m@hp.com> writes: > Thanks Alvaro for your time and suggestions.Yes we do understand that we > are expected to use the higher versions.But as Bruce pointed out > already,the same is NOT recommended when there is NO imperative > reason. Say again? Bruce's point was the opposite: not upgrading is generally more risky than upgrading. It's certainly true that we have sometimes introduced new bugs into minor version updates, but the odds of being bitten by one of those are considerably lower than the odds of being bitten by one of the ones we did fix. This is particularly true when you are talking about a release as ancient as 7.4.2 is. Read the release notes sometime: http://developer.postgresql.org/pgdocs/postgres/release.html and ask yourself if you really want to continue risking exposure to all the known, fixed bugs in the 7.4 series. regards, tom lane
Fine.Thanks for all your suggestions and time. Thanks a lot, Prasanna. -----Original Message----- From: Alvaro Herrera [mailto:alvherre@commandprompt.com] Sent: Wednesday, August 01, 2007 8:48 AM To: Mavinakuli, Prasanna (STSD) Cc: pgsql-general@postgresql.org; Tom Lane; Rao, Srikanth R (STSD); Racharla, Chakravarthy (STSD); Manchenahalli, Raghunandan (STSD); Hebbar, Raghavendra (STSD) Subject: Re: [GENERAL] Core reported from vaccum function. Mavinakuli, Prasanna (STSD) wrote: > Hello Alvaro, > > Thanks Alvaro for your time and suggestions.Yes we do understand that > we are expected to use the higher versions.But as Bruce pointed out > already,the same is NOT recommended when there is NO imperative > reason.Hence we were just in the process of validating and justifying > the upgrade. You are mistaken. Bruce said exactly the opposite. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Hello Alvaro, Thanks Alvaro for your time and suggestions.Yes we do understand that we are expected to use the higher versions.But as Bruce pointed out already,the same is NOT recommended when there is NO imperative reason.Hence we were just in the process of validating and justifying the upgrade. Thanks, Prasanna. -----Original Message----- From: Alvaro Herrera [mailto:alvherre@commandprompt.com] Sent: Tuesday, July 31, 2007 7:18 PM To: Mavinakuli, Prasanna (STSD) Cc: pgsql-general@postgresql.org; Tom Lane; Rao, Srikanth R (STSD); Racharla, Chakravarthy (STSD); Manchenahalli, Raghunandan (STSD); Hebbar, Raghavendra (STSD) Subject: Re: [GENERAL] Core reported from vaccum function. Mavinakuli, Prasanna (STSD) wrote: > > Thanks Alvaro,for your deliberate explanation.But few more > clarifications are requested as we are too novice to postgreSQL. Let me give you this piece of advice, since you are too novice to PostgreSQL: Do NOT continue to run 7.4.2. Upgrade to 7.4.17. Not doing so is just a waste of your time and ours. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Hello Tom and Alvaro, Yes.Sorry for the mistake done because of the wrong interpretation.Now we have the message.We will go ahead with the upgrade. Thanks a lot, Prasanna. -----Original Message----- From: Tom Lane [mailto:tgl@sss.pgh.pa.us] Sent: Wednesday, August 01, 2007 8:51 AM To: Mavinakuli, Prasanna (STSD) Cc: Alvaro Herrera; pgsql-general@postgresql.org; Rao, Srikanth R (STSD); Racharla, Chakravarthy (STSD); Manchenahalli, Raghunandan (STSD); Hebbar, Raghavendra (STSD) Subject: Re: [GENERAL] Core reported from vaccum function. "Mavinakuli, Prasanna (STSD)" <prasanna.b-m@hp.com> writes: > Thanks Alvaro for your time and suggestions.Yes we do understand that > we are expected to use the higher versions.But as Bruce pointed out > already,the same is NOT recommended when there is NO imperative > reason. Say again? Bruce's point was the opposite: not upgrading is generally more risky than upgrading. It's certainly true that we have sometimes introduced new bugs into minor version updates, but the odds of being bitten by one of those are considerably lower than the odds of being bitten by one of the ones we did fix. This is particularly true when you are talking about a release as ancient as 7.4.2 is. Read the release notes sometime: http://developer.postgresql.org/pgdocs/postgres/release.html and ask yourself if you really want to continue risking exposure to all the known, fixed bugs in the 7.4 series. regards, tom lane
Folks, We are observing an issue where postgres does not like UTC0 as a timezone setting on some Unix systems. UTC+0 is something that postgres parses favorably. Is it a known issue that postgres does not like GMT0, UTC0 (which in turn translates to GMT+0 or UTC+0)? Does any version of postgres handle these time zone issues? - Raghu
"Manchenahalli, Raghunandan (STSD)" <raghunandan.manchenahalli@hp.com> writes:
> We are observing an issue where postgres does not like UTC0 as a
> timezone setting on some Unix systems.
If you're seeing system-dependent behavior at all, you must be using PG 7.x.
8.0 and later should accept this consistently.
regards, tom lane