Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier

From: Andres Freund <andres(at)anarazel(dot)de>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Fujii Masao <fujii(at)postgresql(dot)org>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, tharakan(at)gmail(dot)com
Subject: Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier
Date: 2023-01-30 19:49:37
Message-ID: 20230130194937.sjha7e7itbvkp4r3@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2023-01-30 11:30:08 -0800, Nathan Bossart wrote:
> On Mon, Jan 23, 2023 at 07:28:06PM -0800, Andres Freund wrote:
> > After a tiny bit further polishing, and after separately pushing a resource
> > leak fix for walrcv_connect(), I pushed this.
>
> My colleague Robins Tharakan (CC'd) noticed crashes when testing recent
> commits, and he traced it back to e460248. From this information, I
> discovered the following typo:
>
> diff --git a/contrib/dblink/dblink.c b/contrib/dblink/dblink.c
> index 8982d623d3..78a8bcee6e 100644
> --- a/contrib/dblink/dblink.c
> +++ b/contrib/dblink/dblink.c
> @@ -321,7 +321,7 @@ dblink_connect(PG_FUNCTION_ARGS)
> else
> {
> if (pconn->conn)
> - libpqsrv_disconnect(conn);
> + libpqsrv_disconnect(pconn->conn);
> pconn->conn = conn;
> }

Ugh. Good catch.

Why don't the dblink tests catch this? Any chance you or Robins could prepare
a patch with fix and test, given that you know how to trigger this?

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2023-01-30 20:00:55 Re: postgres_fdw uninterruptible during connection establishment / ProcSignalBarrier
Previous Message Andres Freund 2023-01-30 19:48:10 Re: recovery modules