pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Noah Misch <noah@leadboat.com>
To: Andreas Karlsson <andreas@proxel.se>
Cc: pgsql-hackers@postgresql.org
Subject: Re: dblink query interruptibility
Date: Tue, 11 Mar 2025 16:48:39 -0700
Message-ID: <20250311234839.9c.nmisch@google.com> (raw)
In-Reply-To: <bb9f565d-4ca5-4e30-9008-fa538c6895ef@proxel.se>
References: <20231122012945.74@rfd.leadboat.com>
	<bb9f565d-4ca5-4e30-9008-fa538c6895ef@proxel.se>

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=d3c5f37dd543498cc7c678815d3921823...
> 2. https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=e2f65f42555ff531c6d7c8f151526b4ef...

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.





view thread (10+ messages)  latest in thread

Message-ID: <20250311234839.9c.nmisch@google.com>
Permalink:  ../20250311234839.9c.nmisch@google.com/
Also on:    postgresql.org/message-id/20250311234839.9c.nmisch@google.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: noah@leadboat.com, andreas@proxel.se
  Subject: Re: dblink query interruptibility
  In-Reply-To: <20250311234839.9c.nmisch@google.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox