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

Commit746ba76

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 parentfd081ca commit746ba76

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
@@ -1895,6 +1895,8 @@ do_autovacuum(void)
18951895
ScanKeyDatakey;
18961896
TupleDescpg_class_desc;
18971897
inteffective_multixact_freeze_max_age;
1898+
booldid_vacuum= false;
1899+
boolfound_concurrent_worker= false;
18981900

18991901
/*
19001902
* StartTransactionCommand and CommitTransactionCommand will automatically
@@ -2233,6 +2235,7 @@ do_autovacuum(void)
22332235
if (worker->wi_tableoid==relid)
22342236
{
22352237
skipit= true;
2238+
found_concurrent_worker= true;
22362239
break;
22372240
}
22382241
}
@@ -2359,6 +2362,8 @@ do_autovacuum(void)
23592362
}
23602363
PG_END_TRY();
23612364

2365+
did_vacuum= true;
2366+
23622367
/* the PGXACT flags are reset at the next end of transaction */
23632368

23642369
/* be tidy */
@@ -2396,8 +2401,25 @@ do_autovacuum(void)
23962401
/*
23972402
* Update pg_database.datfrozenxid, and truncate pg_clog if possible. We
23982403
* only need to do this once, not after each table.
2404+
*
2405+
* Even if we didn't vacuum anything, it may still be important to do
2406+
* this, because one indirect effect of vac_update_datfrozenxid() is to
2407+
* update ShmemVariableCache->xidVacLimit. That might need to be done
2408+
* even if we haven't vacuumed anything, because relations with older
2409+
* relfrozenxid values or other databases with older datfrozenxid values
2410+
* might have been dropped, allowing xidVacLimit to advance.
2411+
*
2412+
* However, it's also important not to do this blindly in all cases,
2413+
* because when autovacuum=off this will restart the autovacuum launcher.
2414+
* If we're not careful, an infinite loop can result, where workers find
2415+
* no work to do and restart the launcher, which starts another worker in
2416+
* the same database that finds no work to do. To prevent that, we skip
2417+
* this if (1) we found no work to do and (2) we skipped at least one
2418+
* table due to concurrent autovacuum activity. In that case, the other
2419+
* worker has already done it, or will do so when it finishes.
23992420
*/
2400-
vac_update_datfrozenxid();
2421+
if (did_vacuum|| !found_concurrent_worker)
2422+
vac_update_datfrozenxid();
24012423

24022424
/* Finally close out the last transaction. */
24032425
CommitTransactionCommand();

0 commit comments

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