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

On Thu, Mar 11, 2021 at 5:25 PM Fujii Masao <masao.fujii@oss.nttdata.com>
wrote:

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

Thank you for your comment.
The purpose of setting the upper limit was to reduce the amount of log
output.
As you said, it may be better to keep logging to avoid confusing users.

 For that approach,
GETNEWOID_NOTIFY_LIMIT needs to be renamed to GETNEWOID_NOTIFY_MAX_INTERVAL
etc.,
and I think it is necessary to consider how much the setting value of this
variable should be.



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

This message is more user friendly than mine.

Best regards,