Re: BUG #16722: PG hanging on COPY when table has close to 2^32 toasts in the table.

From: tomohiro hiramitsu <hiramit(dot)tm(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, skoposov(at)ed(dot)ac(dot)uk, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #16722: PG hanging on COPY when table has close to 2^32 toasts in the table.
Date: 2021-03-11 05:10:39
Message-ID: CAOR2cEYyXx_oHiiAri7sHHqyEofWcfi9-fDoQMiNKYwvN_ZTmA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

> 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,

Attachment Content-Type Size
v3-0001-GetNewOidWithIndex_log_output.patch application/octet-stream 2.5 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2021-03-11 06:06:02 BUG #16921: small memory leak
Previous Message PG Bug reporting form 2021-03-11 04:47:19 BUG #16920: Can't compile PostGIS with MingW64 against PostgreSQL 14 head