Re: BUG #16722: PG hanging on COPY when table has close to 2^32 toasts in the table.
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Magnus Hagander <magnus@hagander.net>,
Fujii Masao <masao.fujii@oss.nttdata.com>, skoposov@ed.ac.uk,
PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2020-11-19T00:02:34Z
Lists: pgsql-bugs
Andres Freund <andres@anarazel.de> writes: > On 2020-11-18 23:12:10 +0100, Magnus Hagander wrote: >> That said, I'd really prefer to see *some* kind of counter that could >> get people noticing this a bit earlier, rather than just bugging them >> in the logfile once it's gone over a threshold. A statistics counter >> maybe, but I guess that'd have to be tracked at a per-table level to >> be really useful, which would make it potentially fairly expensive to >> keep around... > I'd rather spend effort to solve the underlying issue. It's a bit more > work, but not crazily so, I think. Even the pg_upgrade pieces aren't > that hard to solve. Yeah. If we're going to put work into this, widening the IDs used to identify toast values seems like the right work to be doing. Having said that, I had imagined that we might never have to fix it, because if your table is big enough that it has a problem of this ilk then likely you want to partition it anyway. And partitioning solves the problem since each partition has its own toast table. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Log when GetNewOidWithIndex() fails to find unused OID many times.
- 7fbcee1b2d5f 14.0 landed
-
Add tests for bytea LIKE operator
- eb42110d952f 14.0 cited