After double check, looks `int64` of src/include/c.h is the proper type for it.
Uploaded the v4 patch to fix it.
Thanks.
From: Hongxu Ma <interma@outlook.com>
Sent: Wednesday, September 13, 2023 10:22
To: Tom Lane <tgl@sss.pgh.pa.us>; Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: PSQL error: total cell count of XXX exceeded
Thanks for pointing that, I did miss some other "ncols * nrows" places. Uploaded v3 patch to fix them.
As for the Windows, I didn't test it before but I think it should also have the issue (and happens more possible since
`cellsadded` is also a long type).
My fix idea is simple: define a common long64 type for it.
I referred MSDN: only `LONGLONG` and `LONG64` are 64 bytes. And I assume Postgres should already have a similar type, but only found `typedef long int int64` in src/include/c.h, looks it's not a proper choose.
@Michael Paquier, could you help to give some advices here (which type should be used? or should define a new one?). Thank you very much.
From: Tom Lane <tgl@sss.pgh.pa.us>
Sent: Tuesday, September 12, 2023 12:19
To: Michael Paquier <michael@paquier.xyz>
Cc: Hongxu Ma <interma@outlook.com>; Jelte Fennema <postgres@jeltef.nl>; David G. Johnston <david.g.johnston@gmail.com>; PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: PSQL error: total cell count of XXX exceeded
Michael Paquier <michael@paquier.xyz> writes:
> On Tue, Sep 12, 2023 at 02:39:55AM +0000, Hongxu Ma wrote:
> + long total_cells;
> long is 4 bytes on Windows, and 8 bytes basically elsewhere. So you
> would still have the same problem on Windows, no?
More to the point: what about the multiplication in printTableInit?
The cat's been out of the bag for quite some time before we get to
printTableAddCell.
I'm more than a bit skeptical about trying to do something about this,
simply because this range of query result sizes is far past what is
practical. The OP clearly hasn't tested his patch on actually
overflowing query results, and I don't care to either.
regards, tom lane