Re: snapshot too old issues, first around wraparound and then more.
От | Peter Geoghegan |
---|---|
Тема | Re: snapshot too old issues, first around wraparound and then more. |
Дата | |
Msg-id | CAH2-Wzn0=7Hz4Lt7fSjFMAYEeL3gKXWX99Sif8t=NwB7wdKp3w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: snapshot too old issues, first around wraparound and then more. (Noah Misch <noah@leadboat.com>) |
Ответы |
Re: snapshot too old issues, first around wraparound and then more.
|
Список | pgsql-hackers |
On Tue, Jun 15, 2021 at 11:24 PM Noah Misch <noah@leadboat.com> wrote: > 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. I see. > > > 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). I'm more concerned about 1 (compatibility) than about 4 (perception that we deprecate things when we shouldn't), FWIW. It's not that this is a substandard feature in the same way that (say) contrib/ISN is a substandard feature -- it's not about the quality level per se. Nor is it the absolute number of bugs. The real issue is that this is a substandard feature that affects crucial areas of the system. Strategically important things that we really cannot afford to break. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: