Re: Should we add xid_current() or a int8->xid cast?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Should we add xid_current() or a int8->xid cast?
Дата
Msg-id CA+TgmoYDNXSQj-nEyNgH3WmD0gNepCVqgbrgjrDt2fxLzAVUsQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should we add xid_current() or a int8->xid cast?  (Andres Freund <andres@anarazel.de>)
Ответы Re: Should we add xid_current() or a int8->xid cast?
Список pgsql-hackers
On Fri, Apr 17, 2020 at 1:45 PM Andres Freund <andres@anarazel.de> wrote:
> You seem to be entirely disregarding my actual point, namely that
> txid_current(), as well as some other txid_* functions, have returned
> 64bit xids for many many years. txid_current() is the only function to
> get the current xid in a reasonable way. I don't understand how a
> proposal to add a 32/32 bit representation *in addition* to the existing
> 32 and 64bit representations is going to improve the situation. Nor do I
> see changing txid_current()'s return format as something we're going to
> go for.
>
> I did not argue against a function to turn 64bit xids into epoch/32bit
> xid or such.

I thought we were talking about how the new xid8 type ought to behave.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: proposal - function string_to_table
Следующее
От: Robert Haas
Дата:
Сообщение: Re: xid wraparound danger due to INDEX_CLEANUP false