Re: pg_filedump 9.3: checksums (and a few other fixes)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_filedump 9.3: checksums (and a few other fixes)
Date: 2013-06-10 15:38:37
Message-ID: 23249.1370878717@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Will Crawford 2013-06-10 15:41:35 Re: SPGist "triple parity" concept doesn't work
Previous Message Teodor Sigaev 2013-06-10 15:27:09 Re: SPGist "triple parity" concept doesn't work