Re: pg_amcheck: Fix block number parsing on command line

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_amcheck: Fix block number parsing on command line
Date: 2021-08-20 09:08:26
Message-ID: 84555066-c5ec-46f1-5bbd-e732eea86c1c@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 22.07.21 18:18, Mark Dilger wrote:
>> On Jul 22, 2021, at 7:56 AM, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>>
>> Please check that it's up to speed.
>> <0001-pg_amcheck-Fix-block-number-parsing-on-command-line.patch>
>
> This looks correct to me. Thanks for the fix.

Committed this to 14 and master.

> Your use of strtoul compares favorably to that in pg_resetwal in that you are checking errno and it is not. The consequence is:
>
> bin % ./pg_resetwal/pg_resetwal -e 1111111111111111111111111111111111111111111111111111
> pg_resetwal: error: transaction ID epoch (-e) must not be -1
> bin % ./pg_resetwal/pg_resetwal -e junkstring
> pg_resetwal: error: invalid argument for option -e
> Try "pg_resetwal --help" for more information.
>
> Unless people are relying on this behavior, I would think pg_resetwal should complain of an invalid argument for both of those, rather than complaining about -1. That's not to do with this patch, but if we're tightening up the use of strtol in frontend tools, maybe we can use the identical logic in both places.

Committed a fix for this to master.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message tanghy.fnst@fujitsu.com 2021-08-20 09:14:34 RE: Skipping logical replication transactions on subscriber side
Previous Message Dinesh Chemuduru 2021-08-20 08:24:16 Re: [PROPOSAL] new diagnostic items for the dynamic sql