This has the advantage to make a process more responsive when the
postmaster dies, even if the wait time was rather limited as there was
only a 50ms timeout here. Another advantage of this change is for
monitoring, as we gain a new wait event for the end-of-vacuum
truncation.
Author: Bharath Rupireddy
Reviewed-by: Aleksander Alekseev, Thomas Munro, Michael Paquier
Discussion: https://postgr.es/m/CALj2ACU4AdPCq6NLfcA-ZGwX7pPCK5FgEj-CAU0xCKzkASSy_A@mail.gmail.com
<entry><literal>VacuumDelay</literal></entry>
<entry>Waiting in a cost-based vacuum delay point.</entry>
</row>
+ <row>
+ <entry><literal>VacuumTruncate</literal></entry>
+ <entry>Waiting to acquire an exclusive lock to truncate off any
+ empty pages at the end of a table vacuumed.</entry>
+ </row>
</tbody>
</tgroup>
</table>
return;
}
- pg_usleep(VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL * 1000L);
+ (void) WaitLatch(MyLatch,
+ WL_LATCH_SET | WL_TIMEOUT | WL_EXIT_ON_PM_DEATH,
+ VACUUM_TRUNCATE_LOCK_WAIT_INTERVAL,
+ WAIT_EVENT_VACUUM_TRUNCATE);
+ ResetLatch(MyLatch);
}
/*
case WAIT_EVENT_VACUUM_DELAY:
event_name = "VacuumDelay";
break;
+ case WAIT_EVENT_VACUUM_TRUNCATE:
+ event_name = "VacuumTruncate";
+ break;
/* no default case, so that compiler will warn */
}
WAIT_EVENT_PG_SLEEP,
WAIT_EVENT_RECOVERY_APPLY_DELAY,
WAIT_EVENT_RECOVERY_RETRIEVE_RETRY_INTERVAL,
- WAIT_EVENT_VACUUM_DELAY
+ WAIT_EVENT_VACUUM_DELAY,
+ WAIT_EVENT_VACUUM_TRUNCATE
} WaitEventTimeout;
/* ----------