Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitc6a3897

Browse files
committed
Avoid useless respawining the autovacuum launcher at high speed.
When (1) autovacuum = off and (2) there's at least one database withan XID age greater than autovacuum_freeze_max_age and (3) all tablesin that database that need vacuuming are already being processed by aworker and (4) the autovacuum launcher is started, a kind of infiniteloop occurs. The launcher starts a worker and immediately exits. Theworker, finding no worker to do, immediately starts the launcher,supposedly so that the next database can be processed. But becausedatfrozenxid for that database hasn't been advanced yet, the newworker gets put right back into the same database as the old one,where it once again starts the launcher and exits. High-speed pingpong ensues.There are several possible ways to break the cycle; this seems likethe safest one.Amit Khandekar (code) and Robert Haas (comments), reviewed byÁlvaro Herrera.Discussion:http://postgr.es/m/CAJ3gD9eWejf72HKquKSzax0r+epS=nAbQKNnykkMA0E8c+rMDg@mail.gmail.com
1 parent6546ffb commitc6a3897

File tree

1 file changed

+23
-1
lines changed

1 file changed

+23
-1
lines changed

‎src/backend/postmaster/autovacuum.c

Lines changed: 23 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1898,6 +1898,8 @@ do_autovacuum(void)
18981898
ScanKeyDatakey;
18991899
TupleDescpg_class_desc;
19001900
inteffective_multixact_freeze_max_age;
1901+
booldid_vacuum= false;
1902+
boolfound_concurrent_worker= false;
19011903

19021904
/*
19031905
* StartTransactionCommand and CommitTransactionCommand will automatically
@@ -2307,6 +2309,7 @@ do_autovacuum(void)
23072309
if (worker->wi_tableoid==relid)
23082310
{
23092311
skipit= true;
2312+
found_concurrent_worker= true;
23102313
break;
23112314
}
23122315
}
@@ -2433,6 +2436,8 @@ do_autovacuum(void)
24332436
}
24342437
PG_END_TRY();
24352438

2439+
did_vacuum= true;
2440+
24362441
/* the PGXACT flags are reset at the next end of transaction */
24372442

24382443
/* be tidy */
@@ -2470,8 +2475,25 @@ do_autovacuum(void)
24702475
/*
24712476
* Update pg_database.datfrozenxid, and truncate pg_clog if possible. We
24722477
* only need to do this once, not after each table.
2478+
*
2479+
* Even if we didn't vacuum anything, it may still be important to do
2480+
* this, because one indirect effect of vac_update_datfrozenxid() is to
2481+
* update ShmemVariableCache->xidVacLimit. That might need to be done
2482+
* even if we haven't vacuumed anything, because relations with older
2483+
* relfrozenxid values or other databases with older datfrozenxid values
2484+
* might have been dropped, allowing xidVacLimit to advance.
2485+
*
2486+
* However, it's also important not to do this blindly in all cases,
2487+
* because when autovacuum=off this will restart the autovacuum launcher.
2488+
* If we're not careful, an infinite loop can result, where workers find
2489+
* no work to do and restart the launcher, which starts another worker in
2490+
* the same database that finds no work to do. To prevent that, we skip
2491+
* this if (1) we found no work to do and (2) we skipped at least one
2492+
* table due to concurrent autovacuum activity. In that case, the other
2493+
* worker has already done it, or will do so when it finishes.
24732494
*/
2474-
vac_update_datfrozenxid();
2495+
if (did_vacuum|| !found_concurrent_worker)
2496+
vac_update_datfrozenxid();
24752497

24762498
/* Finally close out the last transaction. */
24772499
CommitTransactionCommand();

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp