Re: Fix race condition in SSI when reading PredXact->SxactGlobalXmin

2025-10-21 Thread Josh Curtis
Thanks for taking a look. I tried adding a reproduction with injection points, but had some trouble with them. I'll give it another go this weekend. I guess one of the commitfest entries should be deleted? I had already made one already. I don't see a way to do that though. https://commitfest.pos

Re: Fix race condition in SSI when reading PredXact->SxactGlobalXmin

2025-10-20 Thread Mihail Nikalayeu
Hello! Josh Curtis : > This is definitely a bit more complex. It requires that SetNewSxactGlobalXmin > is never called when SxactGlobalXmin is invalid to prevent readers from > seeing an invalid transaction ID when they should see a valid one -- I think > this is the case now since before SetNe

Re: Fix race condition in SSI when reading PredXact->SxactGlobalXmin

2025-10-20 Thread Mihail Nikalayeu
To prevent it being lost forever - I registered commitfest entry for it: https://commitfest.postgresql.org/patch/6145/

Re: Fix race condition in SSI when reading PredXact->SxactGlobalXmin

2025-10-18 Thread Mihail Nikalayeu
Hello! Haven't checked the patch yet, but I'd recommend to add .spec reproducer with injection_points to simulate the race in reproducible way. Best regards, Mikhail.

Fix race condition in SSI when reading PredXact->SxactGlobalXmin

2025-09-07 Thread Josh Curtis
DropAllPredicateLocksFromTable, PredicateLockPageSplit, and CheckTableForSerializableConflictIn all assume that if PredXact->SxactGlobalXmin is invalid there are no active serializable transactions and that they can return early as there's no work to do. They don't acquire a LWLock on SerializableX