On 22 November 2016 at 17:49, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
