From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: iwata.aya@fujitsu.com <iwata.aya@fujitsu.com>
Cc: tsunakawa.takay@fujitsu.com <tsunakawa.takay@fujitsu.com>
Cc: k.jamison@fujitsu.com <k.jamison@fujitsu.com>
Cc: 'Kyotaro Horiguchi' <horikyota.ntt@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org <pgsql-hackers@lists.postgresql.org>
Subject: Re: libpq debug log
Date: Wed, 10 Mar 2021 18:24:53 -0500
Message-ID: <2231258.1615418693@sss.pgh.pa.us> (raw)
In-Reply-To: <20210310222546.GA18802@alvherre.pgsql>
References: <20210310222546.GA18802@alvherre.pgsql>
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2021-Mar-10, Tom Lane wrote:
>> After studying this further, I think we should apply the attached
>> patch to remove that responsibility from pqParseInput3's subroutines.
>> This will allow a single trace call near the bottom of pqParseInput3
>> to handle all cases that that function processes.
> Works for me.
I dug into the git history a little and concluded that the reason for
doing that in the subroutines is that 92785dac2 made it so for this
reason:
+ /*
+ * Advance inStart to show that the "D" message has been processed. We
+ * must do this before calling the row processor, in case it longjmps.
+ */
+ conn->inStart = conn->inCursor;
We later gave up on allowing user-defined row processor callbacks,
but we failed to undo this messiness. Looking at what 92785dac2 did
confirms something else I'd been eyeing, which is why these subroutines
have their own checks for having consumed the right amount of data
instead of letting the master check in pqParseInput3 take care of it.
They didn't use to do that, but that check was hoisted up to before the
row processor call, so we wouldn't expose data from a corrupt message to
user code. So I think we can undo that too.
92785dac2 only directly hacked getRowDescriptions and getAnotherTuple,
but it looks like similar error handling was stuck into
getParamDescriptions later.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@alvh.no-ip.org, iwata.aya@fujitsu.com, tsunakawa.takay@fujitsu.com, k.jamison@fujitsu.com, horikyota.ntt@gmail.com, pgsql-hackers@lists.postgresql.org
Subject: Re: libpq debug log
In-Reply-To: <2231258.1615418693@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox