Re: DROP DATABASE deadlocks with logical replication worker in PG 15.1

From: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Lakshmi Narayanan Sreethar <lakshmi(at)timescale(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: DROP DATABASE deadlocks with logical replication worker in PG 15.1
Date: 2023-01-17 10:56:22
Message-ID: CAA4eK1+vzee2_QtxYA5ciBB_Vqj188_1Tf1rme=Shy=dTWhdrA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Sat, Jan 14, 2023 at 10:50 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2023-01-14 08:02:01 -0800, Andres Freund wrote:
>
> I wonder if we ought to put a
> Assert(InterruptHoldoffCount == 0 && CritSectionCount == 0)
>
> in some of the routines in libpqwalreceiver to protect against issues like
> this. It'd be easy enough to introduce one accidentally, due to holding an
> lwlock.
>

This makes sense to me. How about adding this assert in all routines
in libpqwalreceiver that communicate over the network? That means to
add assert except for routines libpqrcv_get_senderinfo,
libpqrcv_get_conninfo, libpqrcv_check_conninfo,
libpqrcv_server_version, libpqrcv_get_backend_pid where we don't
communicate over the network.

There would be one exception to the above which is that we can't add
this assert in libpqrcv_disconnect as that will be called at the time
of proc exit and we set InterruptHoldoffCount as 1 in
proc_exit_prepare. I think that should be fine.

--
With Regards,
Amit Kapila.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2023-01-17 15:07:31 Re: Possible wrong result with some "in" subquery with non-existing columns
Previous Message Xiong He 2023-01-17 09:06:14 Re: Possible wrong result with some "in" subquery with non-existing columns