Re: termination of backend waiting for sync rep generates a junk log message

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: termination of backend waiting for sync rep generates a junk log message
Date: 2011-10-18 21:18:18
Message-ID: 24301.1318972698@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Mon, Oct 17, 2011 at 6:53 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> The simple fix is to change InteractiveBackend() so that it calls
>> CHECK_FOR_INTERRUPTS() before it outputs "backend> ". Thought?

> I'm tempted to say we should do that in PostgresMain() instead, maybe
> something like this:

> diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
> index 976a832..9e5557c 100644
> --- a/src/backend/tcop/postgres.c
> +++ b/src/backend/tcop/postgres.c
> @@ -3769,6 +3769,8 @@ PostgresMain(int argc, char *argv[], const char *username)
> MemoryContextSwitchTo(MessageContext);
> MemoryContextResetAndDeleteChildren(MessageContext);

> + CHECK_FOR_INTERRUPTS();
> +
> initStringInfo(&input_message);

> /*

I don't like putting a CHECK_FOR_INTERRUPTS there, because it's way too
late to throw an error for the previous query.

The real problem here is probably that we're overloading the meaning of
whereToSendOutput. The reset of that variable during shutdown was only
ever meant to prevent output from being sent to a no-longer-present
client. It should *not* result in trying to read a query from stdin.

Another question worth asking is how is it that we're getting to
ReadCommand at all, if we have already determined that the client is
gone. Fixing that with an additional CHECK_FOR_INTERRUPTS seems like
a crock.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-10-18 21:25:05 Re: new compiler warnings
Previous Message Heikki Linnakangas 2011-10-18 20:34:22 Re: new compiler warnings