Обсуждение: [COMMITTERS] pgsql: Use standard interrupt handling in logical replicationlauncher.

Use standard interrupt handling in logical replication launcher.

Previously the exit handling was only able to exit from within the
main loop, and not from within the backend code it calls.  Fix that by
using the standard die() SIGTERM handler, and adding the necessary
CHECK_FOR_INTERRUPTS() call.

This requires adding yet another process-type-specific branch to
ProcessInterrupts(), which hints that we probably should generalize
that handling.  But that's work for another day.

Author: Petr Jelinek
Reviewed-By: Andres Freund
Discussion: https://postgr.es/m/fe072153-babd-3b5d-8052-73527a6eb657@2ndquadrant.com

Branch
------
master

Details
-------
https://git.postgresql.org/pg/commitdiff/2c48f5db64b1b999b08052115a5ce873343c372a

Modified Files
--------------
src/backend/replication/logical/launcher.c | 41 ++++++++++++------------------
src/backend/tcop/postgres.c                |  9 +++++++
src/include/replication/logicallauncher.h  |  2 ++
3 files changed, 27 insertions(+), 25 deletions(-)

Andres Freund <andres@anarazel.de> writes:
> Use standard interrupt handling in logical replication launcher.

This seems to have fixed nightjar's subscription-test failures.
Were you expecting that?

On the less good side, something seems to have broken the pg_upgrade
tests recently on skink and some (not all) of the CLOBBER_CACHE_ALWAYS
animals.

            regards, tom lane

On 2017-06-09 17:47:23 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Use standard interrupt handling in logical replication launcher.
>
> This seems to have fixed nightjar's subscription-test failures.
> Were you expecting that?

Well, hoping ;).  Petr had pointed it out as the probable source.


> On the less good side, something seems to have broken the pg_upgrade
> tests recently on skink and some (not all) of the CLOBBER_CACHE_ALWAYS
> animals.

Yea, I saw skinks failure. Unfortunately it seems we're either not
seeing the bleat because it's in some logfile that's hidden, or it's not
a valgrind visible failure and "just" triggered by the long runtime.

I've a couple things that are of higher priority, but if not I'd planned
to locally try running the pg_upgrade tests under valgrind.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2017-06-09 17:47:23 -0400, Tom Lane wrote:
>> On the less good side, something seems to have broken the pg_upgrade
>> tests recently on skink and some (not all) of the CLOBBER_CACHE_ALWAYS
>> animals.

> Yea, I saw skinks failure. Unfortunately it seems we're either not
> seeing the bleat because it's in some logfile that's hidden, or it's not
> a valgrind visible failure and "just" triggered by the long runtime.

Yeah, I'm also suspecting that it's somehow timing related, because of
the similar-looking CLOBBER_CACHE_ALWAYS failures.  I'm currently trying
to see if I can duplicate it that way.

            regards, tom lane