pgsql: Don't sleep with vacuum_delay_point() while holding locks

Don't sleep with vacuum_delay_point() while holding locks

It's a bad idea to sleep while holding locks, because you might block
another process that wants to acquire the same lock. Furthermore,
it's not safe to call ProcessConfigFile() in a critical section or
while holding locks. So avoid calling vacuum_delay_point() while
holding locks, and also make vacuum_delay_point() return quickly
without sleeping if it's called while interrupts cannot be processed.

To find the vacuum_delay_point() calls that were made while holding
locks, I added "Assert(INTERRUPTS_CAN_BE_PROCESSED())" in
vacuum_delay_point() and ran the regression tests. I didn't include
that Assert in this commit, because there might be more places that do
that that are not covered by the regression tests, including
extensions.

In ginInsertCleanup(), there was already another vacuum_delay_point()
call later in the loop, while not holding any locks, so just remove
the other call that was made while holding the lock.

In hashbucketcleanup(), move the vacuum_delay_point() call up the
stack to its caller. The call in hashbucketcleanup() was not able to
handle interrupts because it held a lock, and because there were no
vacuum_delay_point() or CHECK_FOR_INTERRUPTS() calls in the caller's
loop, the whole hash index vacuuming phase was uninterruptible by
pending shutdown or query cancel. Now it can be interrupted between
buckets. Unfortunately, hashbucketcleanup() has to process all the
bucket's pages in one go without pausing; fixing that would require
changing how hashbucketcleanup()'s lock chaining works.

In acquire_sample_rows(), move the vacuum_delay_point() call in the
loop to between pages, to a time where we're not holding the buffer
lock.

In master, also remove a misleading CHECK_FOR_INTERRUPTS() call from
pgstat_write_statsfile(). It was a no-op because we're always holding
a lock on the current dshash partition at that point. A call that
does nothing is harmless, but it makes you think that the loop is
interruptible when in reality it's not.

Author: Kevin Rocker <me(at)kevinrocker(dot)com>
Author: Andrey Borodin <amborodin(at)acm(dot)org>
Author: Mostafa <mostafa(dot)nabil(dot)nafie(at)gmail(dot)com>
Reported-by: Greg Burd <greg(at)burd(dot)me>
Reported-by: Sergei Kornilov <sk(at)zsrv(dot)org>
Reviewed-by: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Reviewed-by: Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com>
Tested-by: Greg Burd <greg(at)burd(dot)me>
Discussion: https://postgr.es/m/19628-c2b17d358181a1ea@postgresql.org
Discussion: https://postgr.es/m/492c6247-43d3-477b-8981-fb0c56767b38%40app.fastmail.com
Backpatch-through: 14

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/96c99955b62994b2cb47380d84f463456cf16ee5

Modified Files
--------------
src/backend/access/gin/ginfast.c | 6 +++---
src/backend/access/hash/hash.c | 5 +++--
src/backend/commands/analyze.c | 3 +--
src/backend/commands/vacuum.c | 8 ++++++++
src/backend/utils/activity/pgstat.c | 2 --
5 files changed, 15 insertions(+), 9 deletions(-)