Re: [HACKERS] Somebody has broken autovacuum's abort path
On Tue, 2010-01-05 at 03:09 -0500, Tom Lane wrote: > http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguar&dt=2010-01-05%2004:00:03 > (and the same a couple times before this...) > > Core was generated by `postgres: autovacuum worker process regression >'. > Program terminated with signal 6, Aborted. > [New process 9209] > #0 0x0091c402 in __kernel_vsyscall () > #0 0x0091c402 in __kernel_vsyscall () > #1 0x007a9d80 in raise () from /lib/libc.so.6 > #2 0x007ab691 in abort () from /lib/libc.so.6 > #3 0x083393be in ExceptionalCondition ( > conditionName=0x8498e40 "!(rel->rd_refcnt > 0)", > errorType=0x836d218 "FailedAssertion", fileName=0x8498d55 "relcache.c", > lineNumber=1612) at assert.c:57 > #4 0x083324c2 in RelationDecrementReferenceCount (rel=0xb5c641e0) > at relcache.c:1612 > #5 0x0835b562 in ResourceOwnerReleaseInternal (owner=0x92d1058, > phase=RESOURCE_RELEASE_BEFORE_LOCKS, isCommit=0 '\0', isTopLevel=1 '\001') > at resowner.c:251 > #6 0x0835b86f in ResourceOwnerRelease (owner=0x92d1058, > phase=RESOURCE_RELEASE_BEFORE_LOCKS, isCommit=0 '\0', isTopLevel=1 '\001') > at resowner.c:185 > #7 0x080cc5d9 in AbortTransaction () at xact.c:2179 > #8 0x080cc7c7 in AbortOutOfAnyTransaction () at xact.c:3676 > #9 0x0824063e in do_autovacuum () at autovacuum.c:2259 > #10 0x08240b25 in AutoVacWorkerMain (argc=, > argv=) at autovacuum.c:1602 > #11 0x08240c51 in StartAutoVacWorker () at autovacuum.c:1406 > #12 0x0824c0f5 in sigusr1_handler (postgres_signal_arg=10) > I think this can likely be blamed on the HS changes in transaction > abort, since I'm not aware of any other recent changes near here. I haven't knowingly made changes to this code path, nor were there changes to transaction abort in HS. xact_redo_abort() was changed, but that's not what's failing. http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/transam/xact.c?r1=1.277&r2=1.278 -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Somebody has broken autovacuum's abort path
On Tue, 2010-01-05 at 03:09 -0500, Tom Lane wrote: > I think this can likely be blamed on the HS changes in transaction > abort, since I'm not aware of any other recent changes near here. I'll take a look. -- Simon Riggs www.2ndQuadrant.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Somebody has broken autovacuum's abort path
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=jaguar&dt=2010-01-05%2004:00:03 (and the same a couple times before this...) Core was generated by `postgres: autovacuum worker process regression '. Program terminated with signal 6, Aborted. [New process 9209] #0 0x0091c402 in __kernel_vsyscall () #0 0x0091c402 in __kernel_vsyscall () #1 0x007a9d80 in raise () from /lib/libc.so.6 #2 0x007ab691 in abort () from /lib/libc.so.6 #3 0x083393be in ExceptionalCondition ( conditionName=0x8498e40 "!(rel->rd_refcnt > 0)", errorType=0x836d218 "FailedAssertion", fileName=0x8498d55 "relcache.c", lineNumber=1612) at assert.c:57 #4 0x083324c2 in RelationDecrementReferenceCount (rel=0xb5c641e0) at relcache.c:1612 #5 0x0835b562 in ResourceOwnerReleaseInternal (owner=0x92d1058, phase=RESOURCE_RELEASE_BEFORE_LOCKS, isCommit=0 '\0', isTopLevel=1 '\001') at resowner.c:251 #6 0x0835b86f in ResourceOwnerRelease (owner=0x92d1058, phase=RESOURCE_RELEASE_BEFORE_LOCKS, isCommit=0 '\0', isTopLevel=1 '\001') at resowner.c:185 #7 0x080cc5d9 in AbortTransaction () at xact.c:2179 #8 0x080cc7c7 in AbortOutOfAnyTransaction () at xact.c:3676 #9 0x0824063e in do_autovacuum () at autovacuum.c:2259 #10 0x08240b25 in AutoVacWorkerMain (argc=, argv=) at autovacuum.c:1602 #11 0x08240c51 in StartAutoVacWorker () at autovacuum.c:1406 #12 0x0824c0f5 in sigusr1_handler (postgres_signal_arg=10) at postmaster.c:4307 #13 #14 0x0091c402 in __kernel_vsyscall () #15 0x0084b1dd in ___newselect_nocancel () from /lib/libc.so.6 #16 0x082486e0 in ServerLoop () at postmaster.c:1364 #17 0x08249d96 in PostmasterMain (argc=6, argv=0x924d918) at postmaster.c:1069 #18 0x081eb080 in main (argc=6, argv=0x0) at main.c:188 I think this can likely be blamed on the HS changes in transaction abort, since I'm not aware of any other recent changes near here. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers