Re: pg_filedump 9.3: checksums (and a few other fixes) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_filedump 9.3: checksums (and a few other fixes)
Date
Msg-id 23249.1370878717@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_filedump 9.3: checksums (and a few other fixes)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: pg_filedump 9.3: checksums (and a few other fixes)
List pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Jeff Davis wrote:
>> I was hesitant to do too much interpretation of the bits. Do you think
>> it would be better to just remove the test for XMAX_SHR_LOCK?

> I don't know, but then I'm biased because I know what that specific bit
> combination means.  I guess someone that doesn't know is going to be
> surprised by seeing both lock strength bits together .. but maybe
> they're just going to have a look at htup_details.h and instantly
> understand what's going on.  Not sure how likely that is.

I think it's all right because there are only 4 combinations of the two
bits and all 4 will be printed sensibly if we do it this way.  It would
be bad if pg_filedump could print invalid flag combinations in a
misleading way --- but I don't see such a risk here.  So we might as
well go for readability.

The thing I'm not too happy about is having to copy the checksum code
into pg_filedump.  We just got rid of the need to do that for the CRC
code, and here it is coming back again.  Can't we rearrange the core
checksum code similarly to what we did for the CRC stuff recently,
so that you only need access to a .h file for it?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: SPGist "triple parity" concept doesn't work
Next
From: Will Crawford
Date:
Subject: Re: SPGist "triple parity" concept doesn't work