From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Hongxu Ma <interma(at)outlook(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: PSQL error: total cell count of XXX exceeded |
Date: | 2023-11-21 18:11:02 |
Message-ID: | 1523907.1700590262@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> On 2023-Nov-21, Tom Lane wrote:
>> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
>>> It's a bit annoying that the error recovery decision of this code is to
>>> exit the process with an error. [...]
>>> TBH though, I've never hit that code in real usage.
>> Yeah, I think the reason it's stayed like that for 25 years is that
>> nobody's hit the case in practice. Changing the API would be a bit
>> troublesome, too, because we don't know if anybody besides psql
>> uses it.
> True.
It strikes me that perhaps a workable compromise behavior could be
"report the error to wherever we would have printed the table, and
return normally". I'm still not excited about doing anything about
it, but ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2023-11-21 18:13:58 | Re: Add recovery to pg_control and remove backup_label |
Previous Message | Andres Freund | 2023-11-21 17:59:18 | Re: Add recovery to pg_control and remove backup_label |