On 10.04.2025 12:15, Michael Paquier wrote:
Hmm, yeah. Instead of last, it would be better to put it in second
place perhaps, for clarity? That would be the same at the end, but we
would be slightly more consistent with the past logic regarding the
ordering. Does that look OK to you?
Yes, f
On 10.04.2025 05:25, Michael Paquier wrote:
Confirmed. One thing where it would be possible to make things work
is to introduce some persistency of the injection points, say these
are flushed at shutdown. We could do that without touching at the
backend code and only in the module injection_p
Hi Michael, thanks for your answer.
Test 041_checkpoint_at_promote.pl is really good example
of using injection points, but anyway, I still don't see
how injection points can help us here. In failed test case
we started postgres, immediately open psql connection and commit
prepared transaction. P
Hi everyone, thanks for your comments.
I've just wanted to share little cosmetic
fixes for previous patch.
Best Regards,
Maksim MelnikovFrom 748c5fe8efd4c6365f380f7f9bbeba5e91887ab4 Mon Sep 17 00:00:00 2001
From: Maksim Melnikov
Date: Wed, 26 Mar 2025 16:44:09 +0300
Subject: [PATCH] Fix sync_sta
On 27.03.2025 01:13, Michael Paquier wrote:
Tracking if the configuration has been properly loaded in
WalSndCtlData makes sense here, but I am confused by the patch: you
have defined SYNCSTANDBYSDEFINED but sync_standbys_defined never sets
it. It may be simpler to use a separate boolean flag fo
Hi,
On my windows machine I've found unstable test, it fails very rarely,
but anyway, sometimes it fails.
src/test/recovery/t/009_twophase.pl
# Failed test 'Committed prepared transaction is visible to new
snapshot in standby'
# at t/009_twophase.pl line 360.
# got: '0'
# ex
Hi, it seems we can release spinlock twice in
/src/backend/storage/ipc/procsignal.c file, method ProcSignalInit.
void
ProcSignalInit(bool cancel_key_valid, int32 cancel_key)
{
ProcSignalSlot *slot;
uint64 barrier_generation;
...
