Re: setLastTid() and currtid()

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: setLastTid() and currtid()
Дата
Msg-id 23188.1555005973@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: setLastTid() and currtid()  (Andres Freund <andres@anarazel.de>)
Ответы Re: setLastTid() and currtid()  (Michael Paquier <michael@paquier.xyz>)
Re: setLastTid() and currtid()  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2019-04-11 13:27:03 -0400, Tom Lane wrote:
>> I think removing it after feature freeze is not something to do,
>> but +1 for nuking it as soon as the v13 branch opens.  Unless
>> there's some important reason we need it to be gone in v12?

> No, I don't think there really is. They're bogus and possibly a bit
> dangerous, but that's not really new.

> I was mostly just reminded of this when Heikki asked me to improve the
> documentation for heap_get_latest_tid/table_get_latest_tid() - and I was
> briefly wondering whether we could just nuke the whole functionality.
> But it's still used in nodeTidscan.c:

Yeah, if we could simplify the tableam API, that would be sufficient
reason to remove the stuff in v12, IMO.  But if it is outside of that
API, I'd counsel waiting till v13.

            regards, tom lane



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Retronym: s/magnetic disk/main data/
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Enable data checksums by default