Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash
Дата
Msg-id CAMsr+YG=ABchuvCqEfqU26t1zXYZu4qL_EMpJ0LcG-+h5FsT5w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash  (Thomas Munro <thomas.munro@enterprisedb.com>)
Ответы Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 7 August 2017 at 14:04, Thomas Munro <thomas.munro@enterprisedb.com> wrote:
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.

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

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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: [HACKERS] [TRAP: FailedAssertion] causing server to crash
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected