Hi Aleksander,
[ I'm writing this off-list to minimize noise, but we can continue the
discussion in -hackers, if you wish ]
22.01.2024 14:00, Aleksander Alekseev wrote:
Hi,
But node1 knows that it's a standby now and it's expected to get all the
WAL records from the primary, doesn't it?
Ye
Hi,
> But node1 knows that it's a standby now and it's expected to get all the
> WAL records from the primary, doesn't it?
Yes, but node1 doesn't know if it always was a standby or not. What if
node1 was always a standby, node2 was a primary, then node2 died and
node3 is a new primary. If node1 s
Hi Aleksander,
19.01.2024 14:45, Aleksander Alekseev wrote:
it might not go online, due to the error:
new timeline N forked off current database system timeline M before current
recovery point X/X
[...]
In this case, node1 wrote to it's WAL record 0/304DC68, but sent to node2
only record 0/30
Hi,
> it might not go online, due to the error:
> new timeline N forked off current database system timeline M before current
> recovery point X/X
> [...]
> In this case, node1 wrote to it's WAL record 0/304DC68, but sent to node2
> only record 0/304DBF0, then node2, being promoted to primary, fo
Hello hackers,
[ reporting this bug here due to limitations of the bug reporting form ]
When a node, that acted as a primary, becomes a standby as in the
following script:
[ ... some WAL-logged activity ... ]
$primary->teardown_node;
$standby->promote;
$primary->enable_streaming($standby);
$pri
