Re: All-zero page in GIN index causes assertion failure

Re: All-zero page in GIN index causes assertion failure

Re: All-zero page in GIN index causes assertion failure

Re: All-zero page in GIN index causes assertion failure

Re: All-zero page in GIN index causes assertion failure

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Re: All-zero page in GIN index causes assertion failure

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

All-zero page in GIN index causes assertion failure

Re: All-zero page in GIN index causes assertion failure

Re: All-zero page in GIN index causes assertion failure

On 07/20/2015 07:11 PM, Alvaro Herrera wrote:
> Heikki Linnakangas wrote:
>
>> Looking closer, heap vacuum does a similar thing, but there are two
>> mitigating factors that make it safe in practice, I think:
>>
>> 1. An empty heap page is all-zeroes except for the small page header in the
>> beginning of the page. For a torn page to matter, the page would need to be
>> torn in the header, but we rely elsewhere (control file) anyway that a
>> 512-byte sector update is atomic, so that shouldn't happen. Note that this
>> hinges on the fact that there is no special area on heap pages, so you
>> cannot rely on this for index pages.
>>
>> 2. The redo of the first insert/update on a heap page will always
>> re-initialize the page, even when full-page-writes are disabled. This is the
>> XLOG_HEAP_INIT_PAGE optimization. So it's not just an optimization, it's
>> required for correctness.
>
> Hmm, I guess this is a case of an optimization hiding a bug :-(  I mean,
> if we didn't have that, we would have noticed this a lot sooner, I
> imagine.

Yeah, probably.

I came up with the attached, for GIN and SP-GiST. Instead of WAL-logging 
the page initialization in SP-GiST vacuum, I changed it so that it 
simply leaves the page as all-zeroes, and adds it to the FSM. The code 
that grabs a target page from the FSM handles that, and initializes the 
page anyway, so that was simpler. This made the SP-GiST is-deleted flag 
obsolete, it's no longer set, although the code still checks for it for 
backwards-compatibility. (even that may actually be unnecessary, as a 
page that's marked as deleted must also be empty, and wherever we check 
for the deleted-flag, we also check for PageIsEmpty()))

- Heikki

Re: All-zero page in GIN index causes assertion failure

Re: All-zero page in GIN index causes assertion failure

Re: All-zero page in GIN index causes assertion failure