Re: error handling in pqRowProcessor broken

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: error handling in pqRowProcessor broken
Date: 2022-04-19 19:16:05
Message-ID: 2617038.1650395765@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> writes:
> I find that this doesn't work anymore. If you set *errmsgp = "some
> message" and return 0, then psql will just print a result set with zero
> rows.

Ah, I see the problem: a few places in fe-protocol3 didn't get the memo
that conn->error_result represents a "pending" PGresult that hasn't
been constructed yet. The attached fixes it for me --- can you try it
on whatever test case led you to this?

> (Even before the above commit, the handling of the returned message was
> a bit weird: The error output was just the message string, without any
> prefix like "ERROR:".)

libpq's always acted that way for internally-generated messages.
Most of them are so rare that we're probably not used to seeing 'em.
Perhaps there's a case for making it more verbose, but right now
doesn't seem like the time to undertake that.

regards, tom lane

Attachment Content-Type Size
fix-libpq-error-cases.patch text/x-diff 2.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Zhang 2022-04-19 19:54:49 Re: postgres_fdw: commit remote (sub)transactions in parallel during pre-commit
Previous Message Daniel Gustafsson 2022-04-19 19:14:46 Re: Readd use of TAP subtests