On Wed, Nov 5, 2025 at 4:03 PM Xuneng Zhou <[email protected]> wrote: > > On Wed, Nov 5, 2025 at 5:51 PM Alexander Korotkov <[email protected]> > wrote: > > On Mon, Nov 3, 2025 at 5:13 PM Andres Freund <[email protected]> wrote: > > > On 2025-11-03 16:06:58 +0100, Álvaro Herrera wrote: > > > > On 2025-Nov-03, Alexander Korotkov wrote: > > > > > > > > > I'd like to give this subject another chance for pg19. I'm going to > > > > > push this if no objections. > > > > > > > > Sure. I don't understand why patches 0002 and 0003 are separate though. > > > > > > FWIW, I appreciate such splits. Even if the functionality isn't usable > > > independently, it's still different type of code that's affected. And the > > > patches are each big enough to make that worthwhile for easier review. > > > > Thank you for the feedback, pushed. > > Thanks for pushing them! > > > > One thing that'd be nice to do once we have WAIT FOR is to make the common > > > case of wait_for_catchup() use this facility, instead of polling... > > > > The draft patch for that is attached. WAIT FOR doesn't handle all the > > possible use cases of wait_for_catchup(), but I've added usage when > > it's appropriate. > > Interesting, could this approach be extended to the flush and other > modes as well? I might need to spend some time to understand it before > I can provide a meaningful review.
I think we might end up extending WaitLSNType enum. However, I hate inHeap and heapNode arrays growing in WaitLSNProcInfo as they are allocated per process. I found that we could optimize WaitLSNProcInfo struct turning them into simple variables because a single process can wait only for a single LSN at a time. Please, check the attached patch. ------ Regards, Alexander Korotkov Supabase
v1-0001-Optimize-shared-memory-usage-for-WaitLSNProcInfo.patch
Description: Binary data
