Re: Usage of epoch in txid_current
От | Thomas Munro |
---|---|
Тема | Re: Usage of epoch in txid_current |
Дата | |
Msg-id | CA+hUKGL_gdN_wqQXCY6it5pDvphYkFdeehkFzMbO+YtL4_L_Kg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Usage of epoch in txid_current (Heikki Linnakangas <hlinnaka@iki.fi>) |
Ответы |
Re: Usage of epoch in txid_current
Re: Usage of epoch in txid_current |
Список | pgsql-hackers |
On Thu, Mar 28, 2019 at 1:48 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote: > Once we have the FullTransactionId type and basic macros in place, I'm > sure we could tidy up a bunch of code by using them. For example, > TransactionIdInRecentPast() in walsender.c would be simpler, if the > caller dealt with FullTransactionIds rather than xid+epoch. But it makes > sense to do that separately. +1 > > + /* > > + * It is safe to read nextFullXid without a lock, because this is only > > + * called from the startup process, meaning that no other process can > > + * modify it. > > + */ > > + Assert(AmStartupProcess()); > > + > > This assertion fails on WAL replay in single-user mode: Fixed. (Embarrassingly I had that working in v7 but broke it in v8). I decided to do some testing on a 32 bit system, and ran into weird new problem in heap_compute_xid_horizon_for_tuples() which I assumed to be somehow my fault due to the mention of xid horizons, but I eventually realised that master was broken on that machine and followed that up elsewhere. Phew. Thanks for the reviews! Pushed. -- Thomas Munro https://enterprisedb.com
В списке pgsql-hackers по дате отправления: