Outdated comments around HandleFunctionRequest

From: Andres Freund <andres(at)anarazel(dot)de>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Outdated comments around HandleFunctionRequest
Date: 2017-04-05 01:05:25
Message-ID: 20170405010525.rt5azbya5fkbhvrx@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

PostgresMain() has the following blurb for fastpath functions:

/*
* Note: we may at this point be inside an aborted
* transaction. We can't throw error for that until we've
* finished reading the function-call message, so
* HandleFunctionRequest() must check for it after doing so.
* Be careful not to do anything that assumes we're inside a
* valid transaction here.
*/
and in HandleFunctionRequest() there's:

* INPUT:
* In protocol version 3, postgres.c has already read the message body
* and will pass it in msgBuf.
* In old protocol, the passed msgBuf is empty and we must read the
* message here.

which is not true anymore. Followed by:

/*
* Now that we've eaten the input message, check to see if we actually
* want to do the function call or not. It's now safe to ereport(); we
* won't lose sync with the frontend.
*/

which is also not really meaningful, because there's no previous code in
the function.

This largely seems to be damage from

commit 2b3a8b20c2da9f39ffecae25ab7c66974fbc0d3b
Author: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
Date: 2015-02-02 17:08:45 +0200

Be more careful to not lose sync in the FE/BE protocol.

Heikki?

- Andres

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-04-05 01:08:41 Re: Statement timeout behavior in extended queries
Previous Message Tatsuo Ishii 2017-04-05 01:05:19 Re: Statement timeout behavior in extended queries