[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pgsql-bugs
Subject:    Re: BUG #17327: Postgres server does not correctly emit error for max_slot_wal_keep_size being breac
From:       Alex Enachioaie <alex () altmetric ! com>
Date:       2021-12-14 10:03:49
Message-ID: DYN34R.FUPBYLP1ZNOA1 () altmetric ! com
[Download RAW message or body]

Hello Kyotaro,

Exactly and that sounds like an excellent solution.

Thanks!

Alex Enachioaie
Senior Site Reliability Engineer
Altmetric

On Tue, Dec 14 2021 at 10:11:37 +0900, Kyotaro Horiguchi 
<horikyota.ntt@gmail.com> wrote:
> Hello, Alex.
> 
> At Mon, 13 Dec 2021 09:45:51 +0000, Alex Enachioaie 
> <alex@altmetric.com <mailto:alex@altmetric.com>> wrote in
>>  I think I'm happy to leave the method of resolution up to you, I 
>> think
>>  the main point for me would be that when a
>>  replication process gets terminated as a consequence of the 
>> underlying
>>  temporary replication slot reaching max_slot_wal_keep_size
>>  that we log a specific message to indicate to the user the cause of
>>  the termination rather than leave it ambiguous.
> 
> Ah.. I think I got your point.  I thought that the message
> "terminating process to release replication slot X" is showing the
> cause for process termination but actually it doesn't mention the
> reason for releasing replication slot. For persistent slots the
> following message "invalidating slot" does that but that message is
> absent for temporary slots.  However, in that sense, the root reason
> is not clearly stated in any case.
> 
> So I'm going to propose something like the following.
> 
>   LOG:  terminating process nnnnn to release replication slot "slot"
> + DETAIL:  The WAL files retained by the slot is going to exceed 
> max_slot_wal_keep_size.
> 
> Thanks!
> 
> --
> Kyotaro Horiguchi
> NTT Open Source Software Center


[Attachment #3 (text/html)]

<div id="geary-body" dir="auto"><div>Hello Kyotaro,</div><div><br></div><div>Exactly \
and that sounds like an excellent \
solution.</div><div><br></div><div>Thanks!</div><div><br></div><div>Alex \
Enachioaie</div><div>Senior Site Reliability \
Engineer</div><div>Altmetric</div></div><div id="geary-quote" dir="auto"><br>On Tue, \
Dec 14 2021 at 10:11:37 +0900, Kyotaro Horiguchi &lt;horikyota.ntt@gmail.com&gt; \
wrote:<br><blockquote type="cite"><div class="plaintext" style="white-space: \
break-spaces;">Hello, Alex.

At Mon, 13 Dec 2021 09:45:51 +0000, Alex Enachioaie &lt;<a \
href="mailto:alex@altmetric.com">alex@altmetric.com</a>&gt; wrote in  <blockquote> I \
think I'm happy to leave the method of resolution up to you, I think  the main point \
for me would be that when a  replication process gets terminated as a consequence of \
the underlying  temporary replication slot reaching max_slot_wal_keep_size
 that we log a specific message to indicate to the user the cause of
 the termination rather than leave it ambiguous.
</blockquote>
Ah.. I think I got your point.  I thought that the message
"terminating process to release replication slot X" is showing the
cause for process termination but actually it doesn't mention the
reason for releasing replication slot. For persistent slots the
following message "invalidating slot" does that but that message is
absent for temporary slots.  However, in that sense, the root reason
is not clearly stated in any case.

So I'm going to propose something like the following.

  LOG:  terminating process nnnnn to release replication slot "slot"
+ DETAIL:  The WAL files retained by the slot is going to exceed \
max_slot_wal_keep_size.

Thanks!

<div>-- 
</div>Kyotaro Horiguchi
NTT Open Source Software Center
</div></blockquote></div>



[prev in list] [next in list] [prev in thread] [next in thread]