Re: [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid
Дата
Msg-id CAMsr+YEVRL2cX8YtvRjTi6V_zZMAdtr0CO8JXRw1Bu=iKTpOzQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid  (Greg Stark <stark@mit.edu>)
Ответы Re: [PATCH] bigint txids vs 'xid' type, new txid_recent(bigint) => xid  (Craig Ringer <craig@2ndquadrant.com>)
Список pgsql-hackers
On 16 August 2016 at 20:58, Greg Stark <stark@mit.edu> wrote:
On Tue, Aug 16, 2016 at 10:15 AM, Craig Ringer <craig@2ndquadrant.com> wrote:
> I'm surprised the 32-bit xid was ever exposed to the user, rather than a
> 64-bit epoch-extended xid.

Once upon a time we didn't have epoch counting at all.

Makes sense. I didn't dig back too far in history.

Sounds like you're in favour of the 2nd part of the proposal (not covered by the current patch) then.

I haven't yet done the validation required on the epoch logic btw, and I won't be too surprised if it's a bit off. I'm writing a fast xid burn function for use in testing now. I doubt it'll be fast enough to use in routine regression testing since all those clog pages will still take time. But we'll see.  I'd kind of like to be able to avoid all that - advance the xid counter and treat all the old xids as frozen. I don't know or if this is practical within a normal backend though.

Anyway, will follow up with more tests and - probably - a bugfix or three soon.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [RFC] Change the default of update_process_title to off
Следующее
От: Robert Eckhardt
Дата:
Сообщение: Re: Declarative partitioning - another take