Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?
Date: 2016-11-21 08:21:47
Message-ID: CAMsr+YHTd8U+sipRDfxhpOrB77soojzNhBFD0ySp2i4os+RyBA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18 November 2016 at 10:57, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> Hi all
>
> While adding support for logical decoding on standby I noticed that
> the walsender doesn't respect
> SIGUSR1 with PROCSIG_RECOVERY_CONFLICT_DATABASE set.

I have an update on this after further study.

Surprisingly I haven't found a way to crash the walsender with it, but
as expected it is also not really correct as-is.

It's fine for terminating walsender sessions on database drop, or for
holding a lock on an object too long. Termination due to conflict with
vacuum is more problematic because:

* it'll try to terminate a logical decoding walsender even if there's
no real conflict, since only normal relation blocks were affected, not
user catalogs or system catalogs; and

* most of the time its attempts to terminate won't do anything because
there's no xact running on the walsender at the time it checks for
termination.

So that's definitely going to need more work.

I'm still interested in hearing comments from experienced folks about
whether it's sane to do this at all, rather than have similar
duplicate signal handling for the walsender.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2016-11-21 08:29:33 Re: PassDownLimitBound for ForeignScan/CustomScan [take-2]
Previous Message Craig Ringer 2016-11-21 08:17:58 Logical decoding on standby