On Sun, Jul 06, 2025 at 11:07:11AM -0700, Noah Misch wrote:
> A challenge is that the number of files in pg_twophase can exceed
> max_prepared_transactions if we've not yet reached consistency. That happens
> with a sequence like this:
>
> - exactly max_prepared_transactions files are in pg_twophase
> - backup process copies pg_twophase/$file1, then pauses before the next readdir
> - some backend deletes pg_twophase/$file1
> - checkpointer creates pg_twophase/$fileN
> - backup process wakes up and copies remaining pg_twophase files
>
> That's the only problem coming to mind. If that problem doesn't cancel out
> the benefits of scanning pg_twophase early, you may as well do it.
Yeah.. That's where a linked link could become useful, and where
we'll need something different for PreparedXactProcs and the fake proc
entries. Not sure about that yet.
>> By the way, what do you think we should do with 0001 at this stage
>> (your refactoring work with some changes I've sprinkled)? I was
>> looking at it this morning with fresh eyes and my opinion about it is
>> that it improves the situation in all these 2PC callers on HEAD now
>> that we need to deal with fxids for the file names, so that's an
>> independent piece. Perhaps this should be applied once v19 opens for
>> business while we sort out the rest that 0002 was trying to cover?
>
> That looks harmless.
Thanks. I've applied the refactoring piece for now, and marked the CF
entry as returned with feedback. I'm hoping to get back to that for
the September commit fest.
--
Michael
