Re: BUG #16722: PG hanging on COPY when table has close to 2^32 toasts in the table.
tomohiro hiramitsu <hiramit.tm@gmail.com>
From: tomohiro hiramitsu <hiramit.tm@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>,
Magnus Hagander <magnus@hagander.net>, Andres Freund <andres@anarazel.de>,
Fujii Masao <masao.fujii@oss.nttdata.com>, skoposov@ed.ac.uk, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2021-03-11T05:10:39Z
Lists: pgsql-bugs
Attachments
- v3-0001-GetNewOidWithIndex_log_output.patch (application/octet-stream) patch v3-0001
> Perhaps we need a explanation about the logarithmic reduction of the > frequency. It would be something like to avoid showing that message > too often. (And I don't get what the "The query" points to..) I changed the patch comment. > Lately we've been using "%llu" or "%lld" for 64-bit values, and explicitly > casting the argument to [unsigned] long long. That seems to work > everywhere now that we always use our own snprintf code, and it's less > notationally painful than other ways. Thank you for your comment. I modified the patch to use "% llu". In addition, I thought the variable name was long, so I shortened it a little. * v3-0001-GetNewOidWithIndex_log_output.patch Best regards,
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