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

On 2021/03/11 14:10, tomohiro hiramitsu wrote:
> > 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

+ if (retry_count == next_notify && next_notify <= GETNEWOID_NOTIFY_LIMIT)
+ {
+ ereport(LOG,
+ (errmsg("failed to assign new OID in relation \"%s\" after \"%llu\" retries",
+ RelationGetRelationName(relation), (unsigned long long) retry_count)));
+ next_notify *= 2; /* double it for the next notification */
+ }

With the patch, if the number of retries exceeds GETNEWOID_NOTIFY_LIMIT,
we stop logging notification messages. Why do we need to do that?
This behavior may cause user to get confused? For example, they may think
that OID has been successfully assigned because there are no notification
messages in the log for a while. So isn't it better to log notification
messages every GETNEWOID_NOTIFY_LIMIT after the number of retries
exceeds that?

Since users basically don't know the logic of GetNewOidWithIndex(),
they cannot understand what "XXX retries" part in the message means?
I have no good idea for the message. But what about something like
the following?

LOG: still finding an unused OID within relation \"%s\"
DETAIL: \"%llu\" OID candidates were checked, but no unused OID is yet found.

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION