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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pg_filedump 9.3: checksums (and a few other fixes)
Дата
Msg-id 23249.1370878717@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pg_filedump 9.3: checksums (and a few other fixes)  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: pg_filedump 9.3: checksums (and a few other fixes)  (Jeff Davis <pgsql@j-davis.com>)
Список 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 по дате отправления:

Предыдущее
От: Teodor Sigaev
Дата:
Сообщение: Re: SPGist "triple parity" concept doesn't work
Следующее
От: Will Crawford
Дата:
Сообщение: Re: SPGist "triple parity" concept doesn't work