Re: pg_verifybackup: TAR format backup verification

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amul Sul <sulamul(at)gmail(dot)com>, Sravan Kumar <sravanvcybage(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_verifybackup: TAR format backup verification
Date: 2024-09-30 20:11:58
Message-ID: CA+TgmoZ-WRWEuWcTb-g8_gc68PivR+rJ7q-yujqDtgFOo1p+Bg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 30, 2024 at 11:31 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> WFM, modulo the suggestion about changing data types.

I would prefer not to make the data type change here because it has
quite a few tentacles. If I change member_copy_control_data() then I
have to change astreamer_verify_content() which means changing the
astreamer interface which means adjusting all of the other astreamers.
That can certainly be done, but it's quite possible it might provoke
some other Coverity warning. Since this is a length, it might've been
better to use an unsigned data type, but there's no reason that I can
see why it should be size_t specifically: the origin of the value
could be either the return value of read(), which is ssize_t not
size_t, or the number of bytes returned by a decompression library or
the number of bytes present in a protocol message. Trying to make
things fit better here is just likely to make them fit worse someplace
else.

"You are in a maze of twisty little data types, all alike."

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexey Orlov 2024-09-30 20:15:38 Patch: Show queries of processes holding a lock
Previous Message Robert Haas 2024-09-30 20:05:01 Re: pg_verifybackup: TAR format backup verification