On Tue, Jun 15, 2021 at 9:59 PM Noah Misch <n...@leadboat.com> wrote: > Hackers are rather wise, but the variety of PostgreSQL use is enormous. We > see that, among other ways, when regression fixes spike in each vN.1. The > $SUBJECT feature was born in response to a user experience; a lack of hacker > interest doesn't invalidate that user experience.
I agree that it would be good to hear from some users about this. If a less painful workaround is possible at all, then users may be able to help -- maybe it'll be possible to cut scope. > We face these competing > interests, at least: > 1) Some users want the feature kept so their application can use a certain > pattern of long-running, snapshot-bearing transactions. Undoubtedly true. > 2) (a) Some hackers want the feature gone so they can implement changes > without making those changes cooperate with this feature. (b) Bugs in this > feature make such cooperation materially harder. Is that really true? Though it was probably true back when this thread was started last year, things have changed. Andres found a way to work around the problems he had with snapshot too old, AFAIK. > A hacker adopting the feature would be aiming to reduce (2)(b) to zero, > essentially. What other interests are relevant? The code simply isn't up to snuff. If the code was in a niche contrib module then maybe it would be okay to let this slide. But the fact is that it touches critical parts of the system. This cannot be allowed to drag on forever. It's as simple as that. I admit that I think that the most likely outcome is that it gets reverted. I don't feel great about that. What else can be done about it that will really help the situation? No qualified person is likely to have the time to commit to fixing snapshot too old. Isn't that the real problem here? -- Peter Geoghegan
