Re: more descriptive message for process termination due to max_slot_wal_keep_size - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: more descriptive message for process termination due to max_slot_wal_keep_size
Date
Msg-id 20220908.134020.228552226800754222.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: more descriptive message for process termination due to max_slot_wal_keep_size  ("Drouvot, Bertrand" <bdrouvot@amazon.com>)
Responses Re: more descriptive message for process termination due to max_slot_wal_keep_size
Re: more descriptive message for process termination due to max_slot_wal_keep_size
List pgsql-hackers
At Wed, 7 Sep 2022 12:16:29 +0200, "Drouvot, Bertrand" <bdrouvot@amazon.com> wrote in 
> Also, rounding to zero wouldn't occur with "just" displaying
> "oldestLSN - restart_lsn" (as proposed upthread).
..
> Yeah right, but that's already the case in some part of the code, like
> for example in arrayfuncs.c:

Fair points.

> >>         ereport(LOG,
> >>             (errmsg("terminating process %d to release replication slot
> >>             \"%s\" because its restart_lsn %X/%X exceeds the limit by %.1lf
> >>             MB",
> >>                 active_pid, NameStr(slotname),
> >>                 LSN_FORMAT_ARGS(restart_lsn),
> >>                 /* round-up at sub-MB */
> >>                 ceil((double) (oldestLSN - restart_lsn) / 1024 / 102.4) /
> >>                 10),
> 
> typo "/ 102.4" ?

No, it rounds the difference up to one decimal place. So it is devided
by 10 after ceil():p

> >> LOG: terminating process 49539 to release replication slot "rep1"
> >> because its restart_lsn 0/3038000 exceeds the limit by 15.8 MB
> > If the distance were 1 byte, it is shown as "0.1 MB".
> 
> Right and I'm -1 on it, I think we should stick to the "pretty" or the
> "bytes only" approach (my preference being the bytes only one).

Okay. the points you brought up above are sufficient grounds for not
doing so.  Now they are in the following format.

>> LOG: terminating process 16034 to release replication slot "rep1"
>> because its restart_lsn 0/3158000 exceeds the limit by 15368192 bytes

Thank you for the discussion, Bertrand!

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: Handle infinite recursion in logical replication setup
Next
From: Michael Paquier
Date:
Subject: Re: [PATCH] Query Jumbling for CALL and SET utility statements