mirror of
https://github.com/postgres/postgres.git
synced 2026-10-23 13:29:09 +03:00
4a7778ef87
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@kevinrocker.com> Author: Andrey Borodin <amborodin@acm.org> Author: Mostafa <mostafa.nabil.nafie@gmail.com> Reported-by: Greg Burd <greg@burd.me> Reported-by: Sergei Kornilov <sk@zsrv.org> Reviewed-by: Kirill Reshke <reshkekirill@gmail.com> Reviewed-by: Neil Chen <carpenter.nail.cz@gmail.com> Tested-by: Greg Burd <greg@burd.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
PostgreSQL Database Management System ===================================== This directory contains the source code distribution of the PostgreSQL database management system. PostgreSQL is an advanced object-relational database management system that supports an extended subset of the SQL standard, including transactions, foreign keys, subqueries, triggers, user-defined types and functions. This distribution also contains C language bindings. PostgreSQL has many language interfaces, many of which are listed here: https://www.postgresql.org/download/ See the file INSTALL for instructions on how to build and install PostgreSQL. That file also lists supported operating systems and hardware platforms and contains information regarding any other software packages that are required to build or run the PostgreSQL system. Copyright and license information can be found in the file COPYRIGHT. A comprehensive documentation set is included in this distribution; it can be read as described in the installation instructions. The latest version of this software may be obtained at https://www.postgresql.org/download/. For more information look at our web site located at https://www.postgresql.org/.