> On 21 May 2025, at 15:03, Fujii Masao wrote:
>
>
>
> On 2025/05/21 17:35, Andrey Borodin wrote:
>> Well, we implemented this and made tests that do a lot of failovers. These
>> tests observed data loss in some infrequent cases due to wrong new primary
>> selection. Because "few seconds"
On 2025/05/21 17:35, Andrey Borodin wrote:
Well, we implemented this and made tests that do a lot of failovers. These tests observed
data loss in some infrequent cases due to wrong new primary selection. Because "few
seconds" is actually unknown random time.
I see your point. But doesn't a
> On 13 May 2025, at 14:13, Fujii Masao wrote:
>
>
>
> On 2025/05/13 0:47, Andrey Borodin wrote:
>> Moved off from "Small fixes needed by high-availability tools"
>>> On 12 May 2025, at 01:33, Amit Kapila wrote:
>>>
>>> On Fri, May 2, 2025 at 6:30 PM Andrey Borodin wrote:
3. Al
On 2025/05/14 15:54, Alexander Kukushkin wrote:
Hi Fujii,
On Tue, 13 May 2025 at 13:13, Fujii Masao mailto:masao.fu...@oss.nttdata.com>> wrote:
In this case, doesn't the flush LSN typically catch up to the write LSN on
node2
after a few seconds? Even if the walreceiver exits while
On Mon, 12 May 2025 at 17:48, Andrey Borodin wrote:
> Done so. Thanks!
TBH, the current function name pg_last_wal_receive_lsn() is confusing, and
introducing a new one pg_last_wal_receive_unflushed_lsn() doesn't make it
better :(
What about actually adding TWO new functions, pg_last_wal_write_l
Hi Fujii,
On Tue, 13 May 2025 at 13:13, Fujii Masao
wrote:
> In this case, doesn't the flush LSN typically catch up to the write LSN on
> node2
> after a few seconds? Even if the walreceiver exits while there's still
> written
> but unflushed WAL, it looks like WalRcvDie() ensures everything is
Hello, everyone!
> Or might want LSN "flush everything you have written, and return that LSN".
> That will also do the trick, but is not necessary.
I think it is a better option. Less things may go wrong in such a case.
Best regards,
Mikhail.
On 2025/05/13 0:47, Andrey Borodin wrote:
Moved off from "Small fixes needed by high-availability tools"
On 12 May 2025, at 01:33, Amit Kapila wrote:
On Fri, May 2, 2025 at 6:30 PM Andrey Borodin wrote:
3. Allow reading LSN written by walreciever, but not flushed yet
Problem: if we hav
