On Thu, Mar 06, 2025 at 02:57:01PM +0100, Andreas Karlsson wrote: > On 11/22/23 2:29 AM, Noah Misch wrote: > > Something as simple as the following doesn't respond to cancellation. In > > v15+, any DROP DATABASE will hang as long as it's running:
> One of our customers ran into this bug when upgrading from PostgreSQL 14 to > PostgreSQL 16. Your commit[1] fixed this issue in PostgreSQL 17 but the > bugfix was not backported with the explanation below. > > > Code inspection identified the bug at least thirteen years ago, but user > complaints have not appeared. Hence, no back-patch for now. > > But that is as far as I can tell not the case because at least for CREATE > DATABASE the bug was introduced in a commit[2] in PostgeSQL 15. > 1. > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=d3c5f37dd543498cc7c678815d3921823beec9e9 > 2. > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e2f65f42555ff531c6d7c8f151526b4ef7c016f8 The CREATE DATABASE hang is indeed new in v15. The general dblink missed interrupt processing (e.g. pg_cancel_backend response delay) is an old bug. > And now that > we actually have a user complaint what do you think about backporting the > fix? Yes, that seems fine to do. No PGXN module refers to libpq-be-fe-helpers.h so I'm unconcerned about a compatibility risk from adding it. In the context of https://github.com/2ndQuadrant/pglogical/pull/454, I did test the functions against all versions v9.4+. Commit d3c5f37 used the new functions for postgres_fdw, not just dblink. That caused message changes detailed in postgr.es/m/CAHGQGwGpDTXeg8K1oTmDv9nankaKTrCD-XW-tnkzo6%3DE9p5%3Duw%40mail.gmail.com so I'm inclined to omit postgres_fdw changes in back branches. postgres_fdw was already interruptible, so the point of making postgres_fdw adopt the functions was to reduce code duplication. Overall, in the absence of objections, I will queue a task to back-patch the non-postgres_fdw portion of commit d3c5f37 to v13-v16.
