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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
Cc: hiramit(dot)tm(at)gmail(dot)com, kasahara(dot)tatsuhito(at)gmail(dot)com, magnus(at)hagander(dot)net, andres(at)anarazel(dot)de, masao(dot)fujii(at)oss(dot)nttdata(dot)com, skoposov(at)ed(dot)ac(dot)uk, 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-01 03:00:56
Message-ID: 666801.1614567656@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> writes:
> At Mon, 1 Mar 2021 10:56:50 +0900, tomohiro hiramitsu <hiramit(dot)tm(at)gmail(dot)com> wrote in
> + ereport(LOG,
> + (errmsg("failed to assign new OID in relation \"%s\" after "UINT64_FORMAT" retries",

> The embedded UINT64_FORMAT makes the message untranslatable on some
> platforms.

Right, we can't put platform-dependent substrings there.

> The format string should
> be handled separately from the message body. You will find an example
> in WalReceiverMain().

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.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2021-03-01 04:24:20 Two bugs in the RPM specs?
Previous Message Kyotaro Horiguchi 2021-03-01 02:24:52 Re: BUG #16722: PG hanging on COPY when table has close to 2^32 toasts in the table.