Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender? - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?
Date
Msg-id CAMsr+YHTd8U+sipRDfxhpOrB77soojzNhBFD0ySp2i4os+RyBA@mail.gmail.com
Whole thread Raw
In response to Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender?
List pgsql-hackers
On 18 November 2016 at 10:57, Craig Ringer <craig@2ndquadrant.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



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Logical decoding on standby
Next
From: Kouhei Kaigai
Date:
Subject: Re: PassDownLimitBound for ForeignScan/CustomScan [take-2]