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
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 |