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: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: hiramit.tm@gmail.com, kasahara.tatsuhito@gmail.com, magnus@hagander.net, andres@anarazel.de, masao.fujii@oss.nttdata.com, skoposov@ed.ac.uk, pgsql-bugs@lists.postgresql.org
Date: 2021-03-01T03:00:56Z
Lists: pgsql-bugs
Kyotaro Horiguchi <horikyota.ntt@gmail.com> writes:
> At Mon, 1 Mar 2021 10:56:50 +0900, tomohiro hiramitsu <hiramit.tm@gmail.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



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