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

> 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 →
  1. Log when GetNewOidWithIndex() fails to find unused OID many times.

  2. Add tests for bytea LIKE operator