Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash
От | Thomas Munro |
---|---|
Тема | Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash |
Дата | |
Msg-id | CAEepm=3pcN7WgN39ycNSwutK9cGBzEqeMZdDvd2jDy32S5tPCA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash
|
Список | pgsql-hackers |
On Fri, Jul 21, 2017 at 7:17 PM, Kyotaro HORIGUCHI <horiguchi.kyotaro@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. -- Thomas Munro http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: