Re: Usage of epoch in txid_current
От | Thomas Munro |
---|---|
Тема | Re: Usage of epoch in txid_current |
Дата | |
Msg-id | CAEepm=2KeC8xDbEWgDTDObXGqPHFW4kcD7BZXR6NMfiHjjnKhQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Usage of epoch in txid_current (Thomas Munro <thomas.munro@enterprisedb.com>) |
Список | pgsql-hackers |
On Tue, Jul 10, 2018 at 2:15 PM, Thomas Munro <thomas.munro@enterprisedb.com> wrote: > On Tue, Jul 10, 2018 at 1:30 PM, Andres Freund <andres@anarazel.de> wrote:, >>> (errmsg_internal("next transaction ID: %u:%u; next OID: %u", >>> - checkPoint.nextXidEpoch, checkPoint.nextXid, >>> + EpochFromFullTransactionId(checkPoint.nextFullXid), >>> + XidFromFullTransactionId(checkPoint.nextFullXid), >>> checkPoint.nextOid))); >> >> I don't think we should continue to expose epochs, but rather go to full >> xids where appropriate. > > OK, done. Ugh. When I changed pg_resetwal.c to print out the 64 bit value, I broke controldata.c's code that reads those strings back in, as revealed by a failing pg_upgrade test in check-world that I should have waited for. Perhaps we shouldn't change that output format... though I think it does make sense to move forwards here (and probably eventually for the other values too). So here is a version that fixes the parsing problem. Unfortunately pg_upgrade is not allowed to use pg_strtouint64() so for now I jammed the same macrology into controldata.c, but I assume that could be sorted out. -- Thomas Munro http://www.enterprisedb.com
Вложения
В списке pgsql-hackers по дате отправления: