On Fri, Oct 05, 2018 at 12:16:03PM +0900, Michael Paquier wrote: > So, I have come back to this stuff, and finished with the attached > instead, so as the assertion is in a single place. I find that > clearer. The comments have also been improved. Thoughts?
And so... I have been looking at committing this thing, and while testing in-depth I have been able to trigger a case where an autovacuum has been able to be not aggressive but anti-wraparound, which is exactly what should not be possible, no? I have simply created an instance with autovacuum_freeze_max_age = 200000, then ran pgbench with autovacuum_freeze_table_age=200000 set for each table, and also ran installcheck-world in parallel. This has been able to trigger the assertion pretty quickly. Here is the stack trace: #2 0x000055e1a12ef87b in ExceptionalCondition (conditionName=0x55e1a14b45c8 "!((params->is_wraparound && aggressive) || !params->is_wraparound)", errorType=0x55e1a14b459d "FailedAssertion", fileName=0x55e1a14b4590 "vacuumlazy.c", lineNumber=254) at assert.c:54 #3 0x000055e1a0f6c6ad in lazy_vacuum_rel (onerel=0x7f163e7ea710, options=65, params=0x55e1a2eeba70, bstrategy=0x55e1a2f5c1a0) at vacuumlazy.c:253 #4 0x000055e1a0f6c217 in vacuum_rel (relid=1260, relation=0x55e1a2f5d748, options=65, params=0x55e1a2eeba70) at vacuum.c:1714 #5 0x000055e1a0f6a3ac in vacuum (options=65, relations=0x55e1a2f2f050, params=0x55e1a2eeba70, bstrategy=0x55e1a2f5c1a0, isTopLevel=true) at vacuum.c:340 #6 0x000055e1a10c1ddd in autovacuum_do_vac_analyze (tab=0x55e1a2eeba68, bstrategy=0x55e1a2f5c1a0) at autovacuum.c:3121 #7 0x000055e1a10c0e19 in do_autovacuum () at autovacuum.c:2476 $2 = {spcNode = 1664, dbNode = 0, relNode = 1260} (gdb) p onerel->rd_node.relNode $3 = 1260 (gdb) p params->is_wraparound $4 = true (gdb) p aggressive $5 = false I still have the core file, the binaries and the data folder, so it's not a problem to dig into it. -- Michael
signature.asc
Description: PGP signature