Re: [REVIEW] Re: Compression of full-page-writes

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, "Syed, Rahila" <Rahila(dot)Syed(at)nttdata(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [REVIEW] Re: Compression of full-page-writes
Date: 2015-03-09 05:33:28
Message-ID: CAHGQGwE07Egkyk42NF=Yez8NhCN=Cf-85_BaDnikGJ407zuOpQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 16, 2015 at 9:08 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2015-02-16 20:55:20 +0900, Michael Paquier wrote:
>> On Mon, Feb 16, 2015 at 8:30 PM, Syed, Rahila <Rahila(dot)Syed(at)nttdata(dot)com>
>> wrote:
>>
>> >
>> > Regarding the sanity checks that have been added recently. I think that
>> > they are useful but I am suspecting as well that only a check on the record
>> > CRC is done because that's reliable enough and not doing those checks
>> > accelerates a bit replay. So I am thinking that we should simply replace
>> > >them by assertions.
>> >
>> > Removing the checks makes sense as CRC ensures correctness . Moreover ,as
>> > error message for invalid length of record is present in the code ,
>> > messages for invalid block length can be redundant.
>> >
>> > Checks have been replaced by assertions in the attached patch.
>> >
>>
>> After more thinking, we may as well simply remove them, an error with CRC
>> having high chances to complain before reaching this point...
>
> Surely not. The existing code explicitly does it like
> if (blk->has_data && blk->data_len == 0)
> report_invalid_record(state,
> "BKPBLOCK_HAS_DATA set, but no data included at %X/%X",
> (uint32) (state->ReadRecPtr >> 32), (uint32) state->ReadRecPtr);
> these cross checks are important. And I see no reason to deviate from
> that. The CRC sum isn't foolproof - we intentionally do checks at
> several layers. And, as you can see from some other locations, we
> actually try to *not* fatally error out when hitting them at times - so
> an Assert also is wrong.
>
> Heikki:
> /* cross-check that the HAS_DATA flag is set iff data_length > 0 */
> if (blk->has_data && blk->data_len == 0)
> report_invalid_record(state,
> "BKPBLOCK_HAS_DATA set, but no data included at %X/%X",
> (uint32) (state->ReadRecPtr >> 32), (uint32) state->ReadRecPtr);
> if (!blk->has_data && blk->data_len != 0)
> report_invalid_record(state,
> "BKPBLOCK_HAS_DATA not set, but data length is %u at %X/%X",
> (unsigned int) blk->data_len,
> (uint32) (state->ReadRecPtr >> 32), (uint32) state->ReadRecPtr);
> those look like they're missing a goto err; to me.

Yes. I pushed the fix. Thanks!

Regards,

--
Fujii Masao

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2015-03-09 05:42:31 Re: polymorphic types - enforce casting to most common type automatically
Previous Message Amit Kapila 2015-03-09 03:51:41 Re: TABLESAMPLE patch