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

Commit5c5788e

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 parent22b4b55 commit5c5788e

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
@@ -1955,6 +1955,8 @@ do_autovacuum(void)
19551955
ScanKeyDatakey;
19561956
TupleDescpg_class_desc;
19571957
inteffective_multixact_freeze_max_age;
1958+
booldid_vacuum= false;
1959+
boolfound_concurrent_worker= false;
19581960

19591961
/*
19601962
* StartTransactionCommand and CommitTransactionCommand will automatically
@@ -2284,6 +2286,7 @@ do_autovacuum(void)
22842286
if (worker->wi_tableoid==relid)
22852287
{
22862288
skipit= true;
2289+
found_concurrent_worker= true;
22872290
break;
22882291
}
22892292
}
@@ -2410,6 +2413,8 @@ do_autovacuum(void)
24102413
}
24112414
PG_END_TRY();
24122415

2416+
did_vacuum= true;
2417+
24132418
/* the PGXACT flags are reset at the next end of transaction */
24142419

24152420
/* be tidy */
@@ -2447,8 +2452,25 @@ do_autovacuum(void)
24472452
/*
24482453
* Update pg_database.datfrozenxid, and truncate pg_clog if possible. We
24492454
* only need to do this once, not after each table.
2455+
*
2456+
* Even if we didn't vacuum anything, it may still be important to do
2457+
* this, because one indirect effect of vac_update_datfrozenxid() is to
2458+
* update ShmemVariableCache->xidVacLimit. That might need to be done
2459+
* even if we haven't vacuumed anything, because relations with older
2460+
* relfrozenxid values or other databases with older datfrozenxid values
2461+
* might have been dropped, allowing xidVacLimit to advance.
2462+
*
2463+
* However, it's also important not to do this blindly in all cases,
2464+
* because when autovacuum=off this will restart the autovacuum launcher.
2465+
* If we're not careful, an infinite loop can result, where workers find
2466+
* no work to do and restart the launcher, which starts another worker in
2467+
* the same database that finds no work to do. To prevent that, we skip
2468+
* this if (1) we found no work to do and (2) we skipped at least one
2469+
* table due to concurrent autovacuum activity. In that case, the other
2470+
* worker has already done it, or will do so when it finishes.
24502471
*/
2451-
vac_update_datfrozenxid();
2472+
if (did_vacuum|| !found_concurrent_worker)
2473+
vac_update_datfrozenxid();
24522474

24532475
/* Finally close out the last transaction. */
24542476
CommitTransactionCommand();

0 commit comments

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