Re: All-zero page in GIN index causes assertion failure
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2015-08-12T04:19:14Z
Lists: pgsql-hackers
Attachments
- brin-page-init-2.patch (text/x-diff) patch
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
Commits
-
Close some holes in BRIN page assignment
- fc0a6402306d 9.5.0 landed
- ccc4c074994d 9.6.0 landed