Re: termination of backend waiting for sync rep generates a junk log message
От | Tom Lane |
---|---|
Тема | Re: termination of backend waiting for sync rep generates a junk log message |
Дата | |
Msg-id | 24301.1318972698@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: termination of backend waiting for sync rep generates a junk log message (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: termination of backend waiting for sync rep generates a
junk log message
|
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > On Mon, Oct 17, 2011 at 6:53 AM, Fujii Masao <masao.fujii@gmail.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
В списке pgsql-hackers по дате отправления: