Re: new heapcheck contrib module - Mailing list pgsql-hackers

From Mark Dilger
Subject Re: new heapcheck contrib module
Date
Msg-id 11C00553-B306-471E-B216-7B89D9741073@enterprisedb.com
Whole thread Raw
In response to Re: new heapcheck contrib module  (Mark Dilger <mark.dilger@enterprisedb.com>)
List pgsql-hackers

> On Jan 28, 2021, at 9:41 AM, Mark Dilger <mark.dilger@enterprisedb.com> wrote:
>
>
>
>> On Jan 28, 2021, at 9:13 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>>
>> I like 0007 quite a bit and am inclined to commit it soon, as it
>> doesn't depend on the earlier patches. But:
>>
>> - I think the residual comment in processSQLNamePattern beginning with
>> "Note:" could use some wordsmithing to account for the new structure
>> of things -- maybe just "this pass" -> "this function".
>> - I suggest changing initializations like maxbuf = buf + 2 to maxbuf =
>> &buf[2] for clarity.
>
> Ok, I should be able to get you an updated version of 0007 with those changes here soon for you to commit.

I made those changes, and fixed a bug that would impact the pg_amcheck callers.  I'll have to extend the regression
testcoverage in 0008 since it obviously wasn't caught, but that's not part of this patch since there are no callers
thatuse the dbname.schema.relname format as yet. 

This is the only patch for v34, since you want to commit it separately.  It's renamed as 0001 here....



—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company




Attachment

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: vacuum_cost_page_miss default value and modern hardware
Next
From: Michail Nikolaev
Date:
Subject: Re: Thoughts on "killed tuples" index hint bits support on standby