Arthur Petukhovsky

> That's closer to real usage than switching to brand new pageserver. I don't know how often we will need to repair data for a single timeline, probably both cases...

> I would guess, that the pgbench test you've launched might have caused big writes which caused pageserver's walreceiver connection to flicker, hence failing to receive WAL timely. That's a...

> cc @petuhovskiy , you've mentioned that you're testing this already, but the test hadn't failed :) can you share some more details? thanks! https://github.com/zenithdb/zenith/commit/4468797a237ae500e735f702ffcb63acfca47a89 This is the commit with...

Tested locally with a test that counts active timelines: ``` from fixtures.metrics import parse_metrics def test_plenty_timelines(neon_env_builder: NeonEnvBuilder): neon_env_builder.num_safekeepers = 3 neon_env_builder.enable_local_fs_remote_storage() env = neon_env_builder.init_start() # start postgres on each timeline...

#2329 changes timeline handling (restore/create/delete lifecycle) and fixes wal_seg_size late initialization, but leaves most of the other things untouched. The next step after merging that PR can be migration to...

Hi! It's generally hard to say what exactly has gone wrong, but I'll try to guess the probable issue and explain logs a little bit. The issue is in the...

Several weeks ago we talked a bit about this with @arssher and reached a conclusion that we can remove all Neon-specific code from `walsender` and instead interact with replication slots...

> Do you think we could get rid of the rest, too? Not sure, I think f99ccb5041 implemented most of the things I was talking about. I still think it's...

Looks like something is wrong with walreceiver indeed, I'll try to prepare a patch that can fix the issue.

It seems that startup time has become better after the #2253. I'm closing this issue, but if you have another case with a long startup time you can create a...