>
Hi,
Thank you for addressing this issue!
The patch needs to be rebased as it doesn’t apply on master anymore, but here
are some thoughts on the patch in general without testing:
1. Regarding the approach to force a checkpoint on every restartpoint record, I
wonder if it has any
Thanks for your review!
2023年9月27日(水) 8:33 Michael Paquier :
> On Tue, Sep 26, 2023 at 06:44:50PM +0300, Aleksander Alekseev wrote:
> >> And also, I'm afraid that I'm not sure what kind of tests I have to make
> >> for fix this behavior. Would you mind giving me some advice?
> >
> > Personally I
On Tue, Sep 26, 2023 at 06:44:50PM +0300, Aleksander Alekseev wrote:
>> And also, I'm afraid that I'm not sure what kind of tests I have to make
>> for fix this behavior. Would you mind giving me some advice?
>
> Personally I would prefer not to increase the scope of work. Your TAP
> test added
Hi,
> >> IMO a test is needed that makes sure no one is going to break this in
> >> the future.
> >
> > You definitely need more complex test scenarios for that. If you can
> > come up with new ways to make the TAP tests of pg_rewind mode modular
> > in handling more complicated node setups,
On 2023/09/20 12:04, Michael Paquier wrote:
This is a known issue. I guess that the same as this thread and this
CF entry:
https://commitfest.postgresql.org/44/4244/
https://www.postgresql.org/message-id/flat/zarvomifjze7f...@paquier.xyz
I think this is a separate issue, and we should
On Wed, Sep 20, 2023 at 11:46:45AM +0900, Kuwamura Masaki wrote:
> I also found a bug (maybe). If we call `CreateRestartPoint()` during
> crash-recovery, the assertion fails at ComputeXidHorizon() in procarray.c.
> It's inherently orthogonal to the problem I already reported. So you can
>
>> IMO a test is needed that makes sure no one is going to break this in
>> the future.
>
> You definitely need more complex test scenarios for that. If you can
> come up with new ways to make the TAP tests of pg_rewind mode modular
> in handling more complicated node setups, that would be a nice
On Mon, Sep 11, 2023 at 07:04:30PM +0300, Aleksander Alekseev wrote:
> Many thanks for submitting the patch. I added it to the nearest open
> commitfest [1].
>
> IMO a test is needed that makes sure no one is going to break this in
> the future.
You definitely need more complex test scenarios
Hi,
> The attached patch updates minRecoveryPoint and minRecoveryPointTLI at this
> point by mimicking CreateEndOfRecoveryRecord().
> With this patch, you can run pg_rewind with cascade standby immediately.
> (without waiting for checkpointing)
Many thanks for submitting the patch. I added it
> Consider a scenario like this,
>
> Server A: primary
> Server B :replica of A
> Server C :replica of B
>
> and somehow A down ,so B gets promoted.
> Server A: down
> Server B :new primary
> Server C :replica of B
>
> In this case, pg_rewind can be used to reconstruct the cascade; the
source is C
Hi there,
I tested pg_rewind behavior and found a suspicious one.
Consider a scenario like this,
Server A: primary
Server B :replica of A
Server C :replica of B
and somehow A down ,so B gets promoted.
Server A: down
Server B :new primary
Server C :replica of B
In this case, pg_rewind can be
11 matches
Mail list logo
