Re: All-zero page in GIN index causes assertion failure
От | Alvaro Herrera |
---|---|
Тема | Re: All-zero page in GIN index causes assertion failure |
Дата | |
Msg-id | 20150812041914.GD3040@postgresql.org обсуждение исходный текст |
Ответ на | Re: All-zero page in GIN index causes assertion failure (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
Alvaro Herrera wrote: > > BTW, shouldn't there be a step in BRIN vacuum that scans all the BRIN pages? > > If an empty page is missing from the FSM for any reason, there's nothing to > > add it there. > > Probably. I didn't change this part yet. There are two things to fix: > 1. since we use log_newpage_buffer(), we log the initialization but not > the recording into FSM, so the page would be forgotten about. This can > be tested with PageIsEmpty(). An alternative to the vacuum scan is to > use our own WAL record that not only logs the initialization itself but > also the FSM update. Not sure this is worth the trouble. > > 2. additionally, if brin_getinsertbuffer extends the relation but we > crash before the caller initializes it, the page would be detected by > PageIsNew instead and would also need initialization. Added this part. It's using log_newpage_buffer too. The vacuum scan fixes the whole FSM, though, so after vacuum the FSM is up to date. I think we could shave off a few bytes by using a separate WAL record, but I'm not sure it's worth the trouble. I intend to push this tomorrow. I now think the free space calculations are broken, but I'll leave that for later. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-hackers по дате отправления: