On Tue, Jun 15, 2021 at 10:47:45PM -0700, Peter Geoghegan wrote:
> On Tue, Jun 15, 2021 at 9:59 PM Noah Misch <noah@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.
It would be good. But if we don't hear from users in 2021 or 2022, that
doesn't invalidate what users already said in 2016.
> > 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.
When I say "some hackers", I don't mean that specific people think such
thoughts right now. I'm saying that the expected cost of future cooperation
with the feature is nonzero, and bugs in the feature raise that cost. Perhaps
(5) has more weight than (2). (If (2), (3) and (5) all have little weight,
then PostgreSQL should just keep the feature with its bugs.)
> > 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.
Even if we were to stipulate that this feature "isn't up to snuff", purging
PostgreSQL of substandard features may or may not add sufficient value to
compensate for (1) and (4).