On Thu, Apr 10, 2025 at 12:55:54PM +0300, Maksim.Melnikov wrote:
> 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 t
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 Thu, Apr 10, 2025 at 10:12:34AM +0300, Maksim.Melnikov wrote:
> but I am afraid we are loosing this.
>
>if (WalSndCtl->sync_standbys_status & SYNC_STANDBY_INIT)
>{
> if ((WalSndCtl->sync_standbys_status & SYNC_STANDBY_DEFINED) == 0 ||
> lsn <= WalSndCtl->lsn[mode])
>
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
On Wed, Apr 09, 2025 at 06:21:50PM +0300, Maksim.Melnikov wrote:
> 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
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
On Mon, Apr 07, 2025 at 11:39:23PM +0300, Maksim.Melnikov wrote:
> Hi everyone, thanks for your comments.
> I've just wanted to share little cosmetic
> fixes for previous patch.
Note: I would suggest to use a version number for the patches, rather
than a 0003 which usually implies that this is thi
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
On Wed, Mar 26, 2025 at 05:17:17PM +0300, Maksim.Melnikov wrote:
> Test check visibility of prepared transactions in standby after a restart
> while primary is down.
> Failed assert check that changes, commited on transaction on primary node,
> were synchronously replicated to standby node.
> In te
On Wed, 26 Mar 2025 at 21:18, Maksim.Melnikov wrote:
>
> So my question is
> can we accept such behavior as bug of postgres codebase, or, on other way, it
> is bug of unstable test?
> P.S.
> For me it is looking strange, that postgres start processing workload before
> full config initializing.
11 matches
Mail list logo
