From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Re: Use procsignal_sigusr1_handler and RecoveryConflictInterrupt() from walsender? |
Date: | 2016-11-29 14:29:23 |
Message-ID: | CAMsr+YFsFBS71eytfaoPR6AaYc-=ETQaTEm0iZiMi5EFkGba2A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 22 November 2016 at 17:49, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> > Yeah, I definitely don't think it's as simple as just using
>> > procsignal_sigusr1_handler as-is. I expect we'd likely create a new
>> > global IsWalSender and ignore some RecoveryConflictInterrupt cases
>> > when in a walsender, at least PROCSIG_RECOVERY_CONFLICT_SNAPSHOT, and
>> > probably add a new case for catalog_xmin conflicts that's only acted
>> > on when IsWalSender.
>>
>> The global is unncecessary if walsender have a different handler
>> from normal backends. If there's at least one or few additional
>> reasons for signal, sharing SendProcSignal and having dedicate
>> handler might be better.
>
> If no behavior is shared among normal backend and walsender, it
> would be a good reason not to share the handler function. What
> you are willing to do seems so.
I've explored this some more, and it looks like using
procsignal_sigusr1_handler for handling recovery conflicts in the
walsender during logical decoding actually makes a lot of sense.
Almost all behaviour is shared, and so far I haven't needed any
special cases at all. I needed to add a new recovery signal for
conflict with catalog_xmin advance on upstream, but that was it.
Many of the cases make no sense for physical walsenders, so it
probably makes sense to bail out early if it's a physical walsender,
but for a walsender doing logical replication the only one that I
don't think makes sense is conflict with snapshot, which won't get
sent and is harmless if received.
(The comment on it is slightly wrong anyway; it claims it's only used
by normal user backends in transactions, but database conflicts are
fired even when not in an xact.)
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Verite | 2016-11-29 15:02:45 | Re: pg_dump / copy bugs with "big lines" ? |
Previous Message | Stephen Frost | 2016-11-29 14:03:42 | Re: tiny psql doc inconsistency |