Re: PATCH: pageinspect / add page_checksum and bt_page_items(bytea)

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PATCH: pageinspect / add page_checksum and bt_page_items(bytea)
Date: 2017-03-04 17:39:28
Message-ID: f44fc305-fb96-da11-823c-420d00c4236a@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03/04/2017 02:08 PM, Peter Eisentraut wrote:
> On 3/3/17 09:03, Tomas Vondra wrote:
>> Damn. In my defense, the patch was originally created for an older
>> PostgreSQL version (to investigate issue on a production system), which
>> used that approach to building values. Should have notice it, though.
>>
>> Attached is v2, fixing both issues.
>
> Can we have a test case for page_checksum(), or is that too difficult to
> get running deterministicly?
>

I'm not sure it can be made deterministic. Certainly not on heap pages,
because then it'd be susceptible to xmin/xmax changes, but we have other
bits that change even on index pages (say pd_lsn).

So I'm afraid that's not going to fly.

>
> Also, perhaps page_checksum() doesn't need to be superuser-only, but
> I can see arguments for keeping it that way for consistency.
>

Yes, I'll change that.

It won't have much impact in practice, because all functions providing
the page data (get_raw_page etc.) do require superuser. But you can
still input the page as a bytea directly, and it's good practice not to
add unnecessary superuser checks.

regard

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2017-03-04 18:46:05 Re: [PATCH] Use $ parameters as replacement characters for pg_stat_statements
Previous Message Andres Freund 2017-03-04 17:34:23 Re: REINDEX CONCURRENTLY 2.0