Somebody has broken autovacuum's abort path

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)postgreSQL(dot)org
Subject: Somebody has broken autovacuum's abort path
Date: 2010-01-05 08:09:47
Message-ID: 4288.1262678987@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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=<value optimized out>,
argv=<value optimized out>) 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 <signal handler called>
#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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Oleg Bartunov 2010-01-05 08:11:42 Re: KNNGiST for knn-search (WIP)
Previous Message Fujii Masao 2010-01-05 06:55:38 New XLOG record indicating WAL-skipping