▲ | gpavanb 10 hours ago | ||||||||||||||||
The fundamental problem is that a synchronous, lock-based approach is being used in an asynchronous, event-driven context (logical replication). The Postgres team needs to go back to the drawing board and avoid polling altogether and more importantly have event-listener based approaches for primary and replicas separately It's great to see ClickHouse contributing to Postgres though. Cross-pollination between two large database communities can have a multiplying effect. | |||||||||||||||||
▲ | anarazel 9 hours ago | parent [-] | ||||||||||||||||
> The fundamental problem is that a synchronous, lock-based approach is being used in an asynchronous, event-driven context (logical replication). This isn't hit in ongoing replication, this is when creating the resources for a new replica on the publisher. And even there the poll based thing is only hit due to a function being used in a context that wasn't possible at the time it was being written (waiting for transactions to complete in a hot standby). > The Postgres team needs to go back to the drawing board and avoid polling altogether and more importantly have event-listener based approaches for primary and replicas separately That's, gasp, actually how it already works. | |||||||||||||||||
|