Re: MVCC catalog access

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: MVCC catalog access
Дата
Msg-id 2711.1370472988@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: MVCC catalog access  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: MVCC catalog access  (Robert Haas <robertmhaas@gmail.com>)
Re: MVCC catalog access  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Now, I did find a couple that I thought should probably stick with
> SnapshotNow, specifically pgrowlocks and pgstattuple. Those are just
> gathering statistical information, so there's no harm in having the
> snapshot change part-way through the scan, and if the scan is long,
> the user might actually regard the results under SnapshotNow as more
> accurate.  Whether that's the case or not, holding back xmin for those
> kinds of scans does not seem wise.

FWIW, I think if we're going to ditch SnapshotNow we should ditch
SnapshotNow, full stop, even removing the tqual.c routines for it.
Then we can require that *any* reference to SnapshotNow is replaced by
an MVCC reference prior to execution, and throw an error if we actually
try to test a tuple with that snapshot.  If we don't do it like that
I think we'll have errors of omission all over the place (I had really
no confidence in your original patch because of that worry).  The fact
that there are a couple of contrib modules for which there might be an
arguable advantage in doing it the old way isn't sufficient reason to
expose ourselves to bugs like that.  If they really want that sort of
uncertain semantics they could use SnapshotDirty, no?
        regards, tom lane



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

Предыдущее
От: Dmitriy Igrishin
Дата:
Сообщение: Re: About large objects asynchronous and non-blocking support
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: About large objects asynchronous and non-blocking support