Re: getting rid of SnapshotNow

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: getting rid of SnapshotNow
Дата
Msg-id 5525.1374211661@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: getting rid of SnapshotNow  (Noah Misch <noah@leadboat.com>)
Ответы Re: getting rid of SnapshotNow  (Robert Haas <robertmhaas@gmail.com>)
Re: getting rid of SnapshotNow  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> To me, the major advantage of removing SnapshotNow is to force all
> third-party code to reevaluate.  But that could be just as well
> achieved by renaming it to, say, SnapshotImmediate.  If there are
> borderline-legitimate SnapshotNow uses in our code base, I'd lean
> toward a rename instead.  Even if we decide to remove every core use,
> third-party code might legitimately reach a different conclusion on
> similar borderline cases.

Meh.  If there is third-party code with a legitimate need for
SnapshotNow, all we'll have done is to create an annoying version
dependency for them.  So if we think that's actually a likely scenario,
we shouldn't rename it.  But the entire point of this change IMO is that
we *don't* think there is a legitimate use-case for SnapshotNow.

Indeed, I'm thinking I don't believe in SnapshotSelf anymore either.
It's got all the same consistency issues as SnapshotNow.  In fact, it
has *more* issues, because it's also vulnerable to weirdnesses caused by
inconsistent ordering of tuple updates among multiple tuples updated by
the same command.

Why not tell people to use SnapshotDirty if they need a
not-guaranteed-consistent result?  At least then it's pretty obvious
that you're getting some randomness in with your news.

            regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Hari Babu
Дата:
Сообщение: Re: Performance Improvement by reducing WAL for Update Operation
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: [RFC] Minmax indexes