On 7 August 2017 at 14:04, Thomas Munro <thomas.mu...@enterprisedb.com> wrote:
> On Fri, Jul 21, 2017 at 7:17 PM, Kyotaro HORIGUCHI > <horiguchi.kyot...@lab.ntt.co.jp> wrote: > > In vac_truncate_clog, TruncateCLOG is called before > > SetTransactionIdLimit, which advances > > ShmemVariableCache->oldestXid. Given that the assertion in > > TruncateCLOG is valid, they should be called in reverse order. I > > suppose that CLOG files can be safely truncated after advancing > > XID limits. > > If we keep the assertion by changing the order of changes to match the > comment like this, then don't we still have a problem if another > backend moves it backwards because of the data race I mentioned? That > too could be fixed (perhaps by teaching SetTransactionIdLimit not to > overwrite higher values), but it sounds like the assertion might be a > mistake. > <http://www.enterprisedb.com> > I think so - specifically, that it's a leftover from a revision where the xid limit was advanced before clog truncation. I'll be finding time in the next couple of days to look more closely and ensure that's all it is. -- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
