On Thu, Jun 10, 2021 at 5:58 PM Andres Freund <and...@anarazel.de> wrote: > The problem with writing a test is likely to find a way to halfway > reliably schedule a transaction abort after pruning, but before the > tuple-removal loop? Does anybody see a trick to do so?
I asked Alexander about using his pending stop events infrastructure patch to test this code, back when it did the tupgone stuff rather than loop: https://postgr.es/m/CAH2-Wz=Tb7bAgCFt0VFA0YJ5Vd1RxJqZRc I can't see any better way. ISTM that it would be much more useful to focus on adding an assertion (or maybe even a "can't happen" error) that fails when the DEAD/goto path is reached with a tuple whose xmin wasn't aborted. If that was in place then we would have caught the bug in GetOldestNonRemovableTransactionId() far sooner. That might actually catch other bugs in the future. -- Peter Geoghegan
